CCSP Operational Controls and Standards: ITIL, ISO/IEC 20000-1 and Service Management

Cloud operations are governed by a small set of standards and frameworks that each answer a different question, so the first skill in CCSP sub-domain 5.3 is picking the one whose purpose matches the need. Some are certifiable requirements standards (an accredited body audits an organization against them); others are guidance you adopt, map to or assess against, but cannot be certified to as an organization.

Two near-twins matter most. ISO/IEC 20000-1 is the certifiable standard for service management, and ITIL is guidance that helps an organization meet it; ISO/IEC 27001 covers information security, not service management. When a supplier's marketing leans on ITIL, the evidence that actually means something is an ISO/IEC 20000-1 certificate whose scope names the service and location being bought. A certificate is only evidence for what its scope statement covers: one issued for a supplier's managed desktop service in one country says nothing about its database platform run from somewhere else.

HIPAA appears in the official outline as an example of a regulatory source of operational controls. Its Security Rule groups safeguards for electronic protected health information into administrative, physical and technical safeguards, and a cloud provider that handles that information for a covered entity signs a business associate agreement. HIPAA is US law, not a framework you choose; check the current rule text, as HHS proposed revisions to the Security Rule in January 2025.

Choose a control framework by the question the business is asking and by the organization's size and obligations, not by which is most comprehensive.

• Financial-reporting assurance (audit committee, external auditors, internal control over financial reporting) points to COSO. Its five components are the clue.
• Governance of enterprise IT: aligning I&T with business goals, defining governance and management objectives, assigning accountability. That is COBIT 2019, whose objectives are grouped into a governance domain (Evaluate, Direct and Monitor) and four management domains.
• A small organization that needs a short, prioritized list of safeguards to do first fits the CIS Controls. IG1 is the "essential cyber hygiene" set every organization should implement; IG2 and IG3 add safeguards as the organization's risk and resources grow. The principle is proportion: a small organization starts with the prioritized hygiene set and grows into larger programmes later.
• Describing and communicating a cybersecurity program maps well to NIST CSF 2.0. Version 2.0 added the Govern function, which holds risk management strategy, roles and responsibilities, policy, oversight and cybersecurity supply chain risk management; much of that previously sat under Identify.
• A US federal system uses NIST SP 800-53 controls selected through the NIST Risk Management Framework (SP 800-37).

The RMF steps are Prepare, Categorize, Select, Implement, Assess, Authorize and Monitor. Which control baseline (low, moderate or high, published in SP 800-53B) applies is decided by Categorize: the system is categorized by the impact a loss of confidentiality, integrity or availability of its information would cause (FIPS 199). Selecting a baseline before categorization skips the step that justifies it. Prepare comes earlier and covers organization- and system-level preparation (roles, risk strategy, the authorization boundary, the system's assets), but the impact level itself comes out of Categorize. Tailoring adjusts a baseline after it has been selected.

Information security management makes security a managed, risk-based system that is reviewed and improved over time, instead of each team applying controls its own way. ISO/IEC 27001 specifies the requirements for such an ISMS: a defined scope, leadership commitment, an information security policy, risk assessment and risk treatment, internal audit, management review and continual improvement. Because it is a requirements standard, an ISMS can be independently certified.

Key ISMS documents are easy to confuse:

In operations, the information security management practice also has to be built into the other practices. The clearest example is change: if the change authority reviews only technical risk and rollback, security-weakening changes get approved and the security team learns of them afterwards. The principle is that security assessment must sit where the decision is made: a security impact assessment inside change evaluation, before authorization. A control that acts only after approval or after deployment can detect or record a weakness, but it cannot stop the weakness being approved.

Incident management restores normal service as quickly as possible; problem management finds and removes the underlying cause of one or more incidents. An incident can be closed with a restart or workaround before anyone knows why it happened; a problem stays open until the cause is understood and dealt with.

Incident handling is ordered by priority, which combines impact and urgency. Impact is how widely the business is affected (a single internal team, or a revenue-earning service used by all clients); urgency is how quickly the effect becomes serious. Ordering incidents on anything other than both dimensions together misranks them. An incident that keeps recurring and is fixed the same way each time is a signal for problem management: the incident process restores service, but only problem management removes the cause.

Problem management has three phases in ITIL 4:

• Problem identification: from recurring incidents, and also proactively by trend analysis of incident records (for example, noticing that intermittent sign-in delays over several weeks all trace back to one directory service) before a major outage.
• Problem control: analysis of the problem, root-cause investigation and documenting workarounds.
• Error control: managing known errors, problems whose cause has been analysed but not yet removed. A known error record carries the cause and the workaround, so incident handlers can apply it quickly when the issue recurs.

A workaround is not a resolution. Error control keeps reassessing known errors, weighing the cost and risk of living with the workaround against the cost of a permanent solution. When the workaround is no longer acceptable, problem management compares the candidate fixes on cost, risk and benefit, and the chosen fix enters change management as a request for change. A problem is resolved when its cause is dealt with, not when a workaround exists.

Change management (ITIL 4 calls the practice change enablement) makes sure changes are assessed for risk, authorized and scheduled so that they succeed. Every change belongs to one of three types, and each type has its own authorization path.

A vendor-tested patch is not automatically a standard change: standard status comes from a risk assessment of a repeatable procedure, not from where the fix came from. Conversely, a normal change that has run many times the same way without failure is a candidate to be risk-assessed and pre-authorized as a standard change, which speeds it up without weakening control. Moving proven, low-risk work into the standard category is the legitimate way to speed change up; any shortcut that skips assessment removes control rather than streamlining it. ITIL 4 defines only these three types.

A good change or release plan also includes a back-out (remediation) plan: how the service returns to its previous state if the change does not deliver the expected result or causes new faults once it is live. The change authority should not authorize a change without one. After implementation, a post-implementation review confirms whether the change met its objectives; it is a separate step from the back-out plan.

Detecting and handling unauthorized changes

An unauthorized change is a modification to production with no matching approved change record, and how you respond depends on what it did. Detection comes from two sources compared against each other: the provider's control-plane audit log records every configuration change, and the change system records every approved one. Reconciling logged changes against approved change records identifies the changes that bypassed the process. The direction of the comparison matters: the comparison must start from what actually changed in production, because anything without a record is invisible from the change system's side.

Once found, decide on impact:

• The change weakens security and its origin is unknown (for example, public access has been opened on a file share holding regulated records, and nobody can say who did it). Treat it as a security incident first: containing the exposure and investigating come before any change-process paperwork, because the risk is live now.
• The change is known, harmless and made to restore service (for example, an autoscaling cooldown an engineer shortened during a traffic spike to keep the service responsive, with no change raised). Record it retrospectively as an emergency change and assess it, then decide whether to keep or revert it. The response is proportionate to the risk: the change still goes through assessment, but there is no exposure to contain.

Configuration management keeps accurate information about the configuration items (CIs) that make up a service and the relationships between them. A CI is anything that must be managed to deliver a service: a virtual network, an API gateway, a certificate, a machine image, a contract. The records live in a configuration management database (CMDB), part of a wider configuration management system.

Relationships are what make the CMDB useful. To assess the impact of a proposed change, such as upgrading a message queue several applications share, the change authority follows the CI relationships to every dependent service and integration. The CI relationships, not lists of services or histories of activity, are what reveal the technical dependencies an impact assessment needs.

A configuration baseline is an approved, versioned snapshot of a CI's configuration, used as the reference for comparison, audit and rollback. Comparing running configuration with the baseline (drift detection) shows what has changed. Do not confuse it with a known error record (problem management) or the definitive media library (the secure store of authorized software versions used by release and deployment management).

In elastic cloud environments, instances are created and destroyed many times a day, so hand-maintained CMDBs are always stale. The answer is automated discovery: populate CIs from the provider's inventory and APIs, and from infrastructure-as-code definitions, so responders can see the actual configuration of whatever is running when an incident starts. The principle is that the record must change at the speed of the environment.

Release management makes new or changed services and features available for use; deployment management moves new or changed components (software, configuration, infrastructure) into the live environment. In traditional operations the two happen together, so they are easy to merge, but modern cloud delivery separates them.

With feature flags, the point at which customers become exposed to a feature is the release decision, so that is where approval for customer use (including security sign-off) belongs. Security review of the code itself still happens earlier, at merge and in the pipeline, but merge or deployment approval alone does not control when customers begin using a dormant feature. Release planning includes acceptance criteria and the back-out plan described above.

Service-level management sets clear, business-based targets for service performance and makes sure delivery is measured and reviewed against them. Its documents form a chain:

The internal/external split is the tested distinction: a commitment from the provider's own database administration group is an OLA, while a commitment from a third-party telecoms carrier is an underpinning contract. An SLA is with customers, not with supporting teams.

Targets should reflect the customer's end-to-end experience. A provider can meet every component metric (for example, host uptime and ticket-handling times) while users of an online booking service still find their bookings timing out, sometimes called the watermelon effect: green outside, red inside. The fix is targets on what the customer actually does, such as completed bookings and their response time; more or tighter component metrics still measure the parts, not the experience. Contract terms and SLA negotiation with the provider are covered in Domain 6 and in sub-domain 1.2.

Availability, capacity and continuity are three distinct practices: availability management keeps a service usable when agreed through everyday component failures, capacity management makes sure it has enough resources for current and future demand at acceptable cost, and service continuity management keeps it at an agreed level through a disaster such as losing a data centre or region.

Calculating availability

• Single component: availability = MTBF / (MTBF + MTTR), where MTBF is mean time between failures and MTTR is mean time to restore. Only the ratio of the two matters, so doubling MTBF has exactly the same effect as halving MTTR: 400 / (400 + 4) and 200 / (200 + 2) are both about 99.0%.
• Serial dependencies (all must work): multiply availabilities. Two 99.5% components in series give about 99.0%, lower than either.
• Redundant (parallel) components (any one can carry the load): the service fails only if all fail at once, so availability = 1 - (1 - A1) × (1 - A2). Two independent 98% servers give 1 - 0.02 × 0.02 = 99.96%.
• Combined: calculate the redundant group first, then multiply by anything in series with it, such as a single shared database.

Capacity in an elastic cloud

Elasticity does not remove the need for capacity planning. Auto-scaling is bounded by the provider's account quotas and by available capacity, so the capacity plan forecasts demand and acts ahead of need: raising quotas or reserving capacity before a known peak. Once a hard limit is reached, no tuning within it adds capacity. Forecasts must include business inputs, such as a product launch or a seasonal enrolment period, not only past trends. Day-to-day performance monitoring belongs to sub-domain 5.2.

Continuity kept current through change

Continuity plans and recovery environments drift from production unless change management keeps them aligned. Every change evaluation should assess its impact on continuity plans and on recovery-environment configuration items, and implement the change there as well. Aligning recovery environments as part of each change keeps them current continuously, rather than relying on later discovery. BC/DR strategy, RTO/RPO and plan testing are taught in the business continuity and disaster recovery lesson (sub-domain 3.5).

Continual service improvement aligns services with changing business needs through a repeating, measured cycle of improvement. ITIL 4's continual improvement model asks seven questions in order:

1. What is the vision?
2. Where are we now? (a baseline measurement)
3. Where do we want to be? (measurable targets)
4. How do we get there? (the plan)
5. Take action
6. Did we get there? (measure against the baseline)
7. How do we keep the momentum going?

Without a baseline taken before changes, nothing can prove an improvement worked, so it comes straight after agreeing the vision. Deming's Plan-Do-Check-Act cycle expresses the same idea: Plan the change, Do it, Check results against the measurements taken before, and Act to standardize or adjust.

Measure outcomes, not outputs. Delivering every planned output (for example, moving every monitoring dashboard to a new tool) does not mean the goal (faster detection of failures) was met; if the outcome metric has not moved from the baseline, the improvement has not worked and needs another cycle.