8.4 Services, Infrastructure, and Applications

Quick Answer: Services, infrastructure and applications is the component for the technology resources that deliver I&T services — applications, infrastructure, and internal and outsourced services. Cloud and SaaS still sit here. Commonly taught architecture-principle themes (reuse, simplicity, agility, openness) govern how those resources are used; they are themes, not a fake official numbered law. BAI typically builds or acquires them; DSS typically runs them. The exam trap is “cloud is out of COBIT scope.”

This is the seventh slot on every objective card. It is also the slot candidates most often exile to “the IT operations team,” which Chapter 6 already told you not to do. A governance system that cannot run on anything is a binder. A governance system that runs only on last decade’s on-premises estate is a binder that has not noticed the contract register.

What actually sits in this component

Name the contents the way Foundation options name them:

The last row is the one that catches people. Outsourcing does not move the resource into a different component, a different domain, or “out of COBIT.” The service is still the technology foundation of the objective. What changes is who operates it (structures + people + contracts) and which variant of the component you write down. The slot name does not change.

Examples you should be able to drop into the slot without blinking: an ERP, an EHR, a payment switch, an identity platform, a laptop image, a factory historian, a SIEM, a public-cloud landing zone, a SaaS HR system, a managed SOC, a colocation cage. All of those are services, infrastructure and applications. None of them is the information content they carry (that is the information component). None of them is the CAB that approves their changes (structures). None of them is the analyst who can run them (people, skills and competencies).

Architecture-principle themes — not a numbered official law

Enterprises do not assemble this component by collecting random tools. Teaching materials talk about architecture principles that govern use of I&T resources. The themes you will most often meet are:

• Reuse — prefer existing services and platforms over a new stack for every request.
• Simplicity — fewer moving parts, fewer special cases, fewer unmaintainable exceptions.
• Agility — the estate can change when strategy, risk, or design factors change (the dynamic-governance-system idea, expressed in technology).
• Openness — usable interfaces, avoidable lock-in, ability to integrate and to exit.

Label these as architecture-principle themes, not as “COBIT’s Four Official Architecture Laws.” ISACA does not ask Foundation candidates to recite a fake numbered statute. If a stem describes a team that builds a third integration platform because the first two were “not invented here,” the theme in play is reuse. If a stem describes a maze of one-off scripts that only one engineer understands, simplicity is the theme. If a stem describes a six-month hardware refresh that cannot follow a strategy change, agility is the theme. If a stem describes a SaaS contract with no export path, openness is the theme.

Principles, policies and frameworks is the component that writes those themes down as architecture policy. This component is the estate that must obey them. Do not merge the two slots.

Relationship to BAI and DSS

You do not need the full 40-objective walk-through yet (that is later). You do need the domain pairing that items use:

• BAI (Build, Acquire and Implement) is where the enterprise typically creates or buys the applications, infrastructure, and services — BAI03 Managed Solutions Identification and Build, BAI07 Managed IT Change Acceptance and Transitioning, BAI09 Managed Assets, and their neighbors.
• DSS (Deliver, Service and Support) is where the enterprise typically operates them — DSS01 Managed Operations, DSS02 Managed Service Requests and Incidents, DSS03 Managed Problems, DSS04 Managed Continuity.

So the same component appears on both sides of the life cycle. BAI fills the slot. DSS keeps the slot alive. MEA asks whether the slot still meets the objective. APO02/APO03 (strategy and architecture) decide which themes apply. If a stem says “we implemented the application, so COBIT is finished,” the candidate forgot DSS. If a stem says “operations owns this component, so BAI is irrelevant,” the candidate forgot how the resource got there.

Cloud does not break the pairing. A SaaS onboarding is still acquire/implement. A SaaS outage is still deliver/service/support. The provider’s shared-responsibility matrix changes activities. It does not delete the component or the domains.

Scenario: Cedarline Health moves the EHR to SaaS

Cedarline Health runs a hospital EHR. The board approves a move from a self-hosted suite to a SaaS clinical platform on a public-cloud region. A director tells the governance working group, “COBIT no longer applies — we will not have infrastructure. Cloud is out of scope. Architecture principles were for the data-center era.”

That sentence fails the Foundation exam and fails EGIT.

The SaaS EHR is still an application. The cloud region and the identity integration are still infrastructure. The vendor’s uptime service is still an outsourced service. All three sit in services, infrastructure and applications. BAI still has to acquire and transition. DSS still has to operate the hospital’s side of the shared model (identity, endpoints, downtime procedures, incident comms). Architecture-principle themes still apply: reuse the existing identity service instead of a new login silo; keep the integration simple; stay agile enough to add a clinic; insist on openness so records can be exported if the contract ends.

What does change is the variant: fewer on-premises servers, more contract and access-management work, different skills (previous section), different information flows (section 8.1), and a culture that must not treat “the vendor will handle it” as a blank check (section 8.2). Variants tailor the slot. They do not retire it. Cloud is not a loophole.

Exam traps for this component

• Cloud is out of COBIT scope: The highest-yield trap. Cloud and SaaS are in this component.
• On-premises only: Internal and outsourced services both count.
• This slot is “the IT department”: End-to-end coverage includes OT, cloud, and business-owned SaaS.
• Fake numbered architecture law: Reuse, simplicity, agility, and openness are commonly taught themes, not a statute of four official commandments you must number 1–4 on the answer sheet.
• Confusing the resource with information: The EHR platform is this component; the patient-risk report it produces is information.
• Confusing the resource with skills: Buying the platform does not staff the analysts (Larkspur Bank).

How items are written

• SaaS / public cloud / MSSP → still this component.
• “Cloud is out of scope” → reject.
• BAI versus DSS → build/acquire/implement versus deliver/service/support of the same component.
• Architecture principles → themes that govern use; not a fake numbered official law; not a replacement for BAI/DSS.
• Tool without operators → people, skills and competencies is also empty; do not pretend the purchase filled both slots.

You now have all four remaining components from the seven. Chapter 9 puts the seven back together — RACI, integration, and how every objective is described with the full set. Recite the four names in this chapter until you can separate what people know (information), what they will do (culture), what they can do (skills), and what they run it on (this component).