Release and deployment management

ISO/IEC 20000-1:2018 Clause 8.5.3 requires you to plan, schedule, and control every release deployment into production so production integrity is protected. Operationally, you need a defined release process with approvals, separation of duties, pre-deployment checks, controlled execution, rollback capability, and auditable evidence for each deployment. ¹

Key takeaways:

• Your control objective is production integrity: only authorized, tested, scheduled changes reach the live environment. ¹
• Auditors look for repeatable workflow evidence, not “heroic” deployments done by memory.
• A compliant release process ties together change enablement, configuration management, testing, and incident/problem feedback loops.

Release and deployment management is where good intentions go to die in audit. Most organizations have pieces of the process (a ticketing tool, a CI/CD pipeline, a CAB), but not a single controlled path that proves each production deployment was planned, scheduled, executed, and validated without compromising production integrity.

Clause 8.5.3 is short, but it is not lightweight. “Plan, schedule, and control” means you can reconstruct what happened for any release: who approved it, what was deployed, when it ran, how risk was assessed, what checks were performed, and what you would do if it failed. “Integrity of the live environment” is broader than uptime. It includes preventing unauthorized code, configuration drift, inconsistent dependencies, and unsafe access paths into production. ¹

This page gives requirement-level implementation guidance you can apply immediately: applicability scoping, a step-by-step operating procedure, minimum evidence artifacts, common audit traps, and a practical execution plan. The goal is simple: every production deployment follows one controlled mechanism, and you can prove it on demand.

Regulatory text

Requirement (excerpt): “The organization shall plan, schedule, and control the deployment of releases into the live environment, ensuring integrity of the live environment is protected.” ¹

Operator interpretation:

• Plan: Define what is being released, prerequisites, testing gates, deployment method, rollback approach, and ownership.
• Schedule: Choose a controlled window (or controlled automation rules) with appropriate business coordination, customer communications when needed, and conflict checks with other changes.
• Control: Enforce approvals, access restrictions, verified artifacts, segregation of duties where feasible, and standard execution steps so deployments are repeatable and auditable.
• Protect live integrity: Prevent unauthorized or unvalidated changes, reduce human error, maintain environment consistency, and confirm post-deployment service health. ¹

Plain-English requirement (what auditors mean)

You must be able to answer, for any production release:

1. Who authorized it and why (business justification and risk acceptance),
2. What changed (code/config versions and dependencies),
3. How it was validated (test evidence and pre-flight checks),
4. When it was deployed (schedule and deployment window controls),
5. How it was deployed (controlled mechanism, automation logs, runbooks),
6. What happened after (monitoring, verification, incidents, rollback if needed).

If you cannot reconstruct those facts quickly, you are not “controlling” releases, even if you have a CI/CD pipeline.

Who it applies to (entity and operational context)

This requirement applies to any organization providing or supporting services where changes are deployed into a live/production environment, including:

• Internal IT organizations running enterprise services.
• Managed service providers and SaaS providers operating customer-facing production systems.
• Teams deploying infrastructure, configuration, data schema, features, patches, or pipeline changes that impact production behavior. ¹

Include in scope:

• Application releases (web, mobile, backend services).
• Infrastructure-as-code and cloud changes (network, IAM policies, Kubernetes manifests).
• Configuration changes (feature flags, runtime parameters).
• Database changes (migrations, stored procedures).
• Emergency fixes (hotfixes) and security patches.

A common scoping failure: treating “release management” as only software code. Auditors often sample “non-code” production changes because those are frequent sources of integrity issues (permissions, routing, firewall rules, misconfigurations).

What you actually need to do (step-by-step)

Below is a pragmatic operating procedure you can implement in a ticketing system plus CI/CD.

1) Establish a single controlled path into production

• Define what counts as a release and what counts as a deployment in your environment (they can be separate events).
• Require that all production deployments originate from an approved record (change, release ticket, or equivalent).
• Restrict production access so “side-door” changes are blocked or strongly detected.

Control intent: production changes occur only through managed workflow and authenticated automation.

2) Standardize release planning inputs

For each release, capture:

• Scope and components (services, modules, infrastructure items).
• Risk and impact summary (customer impact, data impact, dependency impact).
• Preconditions (backups, capacity checks, maintenance notice, third-party readiness).
• Test gates (unit/integration, security checks where applicable, UAT evidence).
• Rollback strategy (technical method and decision trigger).
• Implementation owner and approvers.

Keep this lightweight for low-risk standard changes, but never “blank.”

3) Schedule deployments with conflict and readiness checks

• Set rules for scheduling (change calendar, blackout periods, peak business times).
• Check for conflicts with other releases and major operational events.
• Coordinate communications (internal stakeholders; customers if required by your service commitments).
• Confirm readiness: artifacts built, approvals complete, dependencies available.

If you deploy continuously, “schedule” can mean defined automation rules plus change windows for high-risk services. The point is controlled timing, not manual meetings.

4) Control execution with gates and separation

Implement enforceable gates:

• Approval gate before production deploy (human approval, automated policy check, or both depending on risk).
• Artifact integrity gate: deploy only from a controlled repository; verify version/commit/tag.
• Access gate: limit who can trigger production deployments; log all actions.
• Runbook/automation gate: deployments follow documented steps or standardized pipelines, not ad hoc commands.

Where segregation of duties is feasible, separate:

• People who approve from people who deploy.
• People who develop from people who administer production. If your organization is small, document compensating controls (peer review, automated checks, post-deploy review).

5) Validate and protect production integrity post-deploy

Define required post-deployment actions:

• Smoke tests or synthetic checks.
• Monitoring review (errors, latency, saturation indicators relevant to the service).
• Confirm configuration baselines and critical security controls are intact.
• Record outcome: success, partial success with follow-ups, or rollback.

If rollback occurs, treat it as a controlled deployment with its own evidence trail.

6) Close the loop: link releases to incidents and known errors

A release process that never learns is fragile.

• Link production incidents back to the release record when the release is suspected or confirmed.
• Feed problem management with repeated release-related failures.
• Update release templates, gates, and test coverage based on failures.

This closes the integrity loop: your process reduces recurrence over time.

Required evidence and artifacts to retain

Auditors typically sample recent releases and expect end-to-end traceability. Retain:

Policy and process artifacts

• Release and deployment management procedure (scope, roles, gates, emergency path).
• Change/release classification and risk rating criteria.
• Access control policy for production deploy permissions.

Per-release/per-deployment records

• Approved release/change record with scope, risk, approvers, and scheduled window.
• Build and artifact provenance (build logs, artifact repository reference, version/commit hash).
• Test evidence aligned to the release risk (automated test reports, UAT sign-off if applicable).
• Deployment logs (pipeline logs, runbook execution evidence, timestamps, deployer identity).
• Post-deployment validation results and monitoring screenshots/links.
• Backout/rollback plan and evidence if executed.
• Communications record where relevant (stakeholder notice, status update).

System integrity artifacts

• Configuration baseline references (what “good” looks like).
• Exceptions register for emergency changes with after-the-fact review.

Tip for speed: Daydream can centralize release evidence requests by mapping each deployment to a checklist of required artifacts and collecting pipeline logs and approvals in one audit-ready package, so sampling does not become a cross-tool scavenger hunt.

Common exam/audit questions and hangups

Expect these, and prepare short, evidenced answers:

• “Show me your last production deployment. Where is the approval and risk assessment?”
• “How do you prevent unauthorized production changes outside the pipeline?”
• “How do you know what version is running in production right now?”
• “What is your emergency release process, and how do you review it afterward?”
• “How do you validate production health after deployment?”
• “How do you handle failed deployments and rollbacks?”

Hangup pattern: teams can explain the process verbally but cannot produce consistent artifacts for sampled releases.

Frequent implementation mistakes and how to avoid them

1. Process exists only for ‘major’ releases.
   Fix: define minimum controls for every production deployment; scale rigor by risk.

2. Approvals are informal (chat messages) and not retained.
   Fix: require approvals in a system of record with identity and timestamp.

3. No artifact provenance.
   Fix: deploy only from a controlled artifact repository; record immutable identifiers.

4. Emergency changes become a loophole.
   Fix: document an emergency path with after-the-fact review and trend reporting.

5. Post-deploy validation is tribal knowledge.
   Fix: define minimum smoke tests/monitoring checks per service tier; capture evidence.

6. CI/CD is treated as “proof.”
   Fix: pipelines are helpful, but auditors still need the “why, who, when, what changed” trail tied to each deployment.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the source catalog, so treat enforcement risk as indirect: failed release control commonly drives customer-impacting outages, security exposure from unauthorized changes, and audit findings that cascade into broader service management nonconformities. Your practical risk is operational disruption plus loss of confidence in your control environment. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and make it auditable)

• Appoint a release process owner and define in-scope production environments.
• Document the “one path to prod” rule and the emergency path.
• Create a minimum release record template (scope, risk, approval, rollback, validation).
• Start retaining evidence for every production deployment, even if the process is imperfect.
• Lock down production deploy permissions and confirm logging is enabled.

By 60 days (standardize and add gates)

• Implement risk-based release categories (standard/normal/emergency) with required gates.
• Add approval gates in the ticketing system or pipeline for higher-risk deployments.
• Standardize post-deploy validation steps by service tier.
• Create a release calendar or conflict-check mechanism; document blackout rules.
• Run an internal “mock audit” by sampling releases and verifying traceability.

By 90 days (reduce variance and close loops)

• Reduce exceptions: migrate remaining teams and services onto the standard release path.
• Add automated policy checks (artifact integrity, required approvals, required test completion).
• Establish recurring review of release failures, rollbacks, and emergency changes.
• Tie release records to configuration management references so you can prove what is live.
• Prepare an auditor packet template: policy, process map, and a sample release evidence bundle.

Frequently Asked Questions

Does ISO 20000 require a CAB meeting for every deployment?

Clause 8.5.3 requires planning, scheduling, and control of deployments, not a specific meeting format. If you can show approvals, risk treatment, and controlled execution without a CAB, that can still meet the requirement. ¹

We do continuous deployment. How do we “schedule” releases?

Define scheduling rules as policy: allowed deployment windows by service, automated change calendar entries, and constraints for high-risk systems. Auditors want controlled timing and conflict management, even if deployment is automated. ¹

What counts as “integrity of the live environment”?

Treat integrity as protection against unauthorized, untested, or inconsistent changes in production, plus verification that the service operates as intended after deployment. Evidence comes from access controls, artifact provenance, and post-deploy validation records. ¹

Are configuration changes and feature flags in scope?

Yes if they change production behavior. Put them through the same controlled path with approvals, traceability, and verification, even if the deployment mechanism differs from code releases. ¹

How do we handle emergency fixes without failing audit?

Use an emergency path with documented criteria, minimal safe testing, constrained approvals, and mandatory after-the-fact review that links to the incident and records final outcomes. Treat “emergency” as a category with controls, not a bypass. ¹

What’s the minimum evidence set per deployment if we need to keep it lightweight?

Keep, at minimum, the approved record, what changed (version/artifact), who executed, when it ran, and post-deploy validation outcome. If any of those are missing, sampling becomes painful and findings become likely. ¹

Footnotes

1. ISO/IEC 20000-1:2018 Information technology — Service management