Change Management for Applications Deployed on Core Platform
For applications deployed on Core Platform, change management commonly needs to show that production changes are requested, reviewed, validated, deployed through a controlled process, and retained with evidence for review or audit.
That means each change can show:
- What changed and why.
- Who reviewed and approved the change.
- Which P2P validation stages ran before production.
- Which version or artifact reached production.
- When production deployment happened.
- Any rollback, incident, emergency-change, or post-change review notes.
Change Management With Core Platform
For applications, Core Platform captures those requirements in a standard pull-request-to-production path:
- Open a PR for the application change. Use the PR description to capture what is changing, why it is needed, affected environments, test evidence, production impact, and rollback or recovery notes.
- Link the PR to the related issue, incident, or request when there is a separate source record.
- Use CODEOWNERS to route review to the maintainers responsible for the affected application code, configuration, templates, or workflows.
- Confirm GitHub requested the expected CODEOWNERS reviewers and that required approvals are recorded on the PR.
- The standard P2P then takes the change through all agreed stages, including functional testing, stubbed functional testing, integration testing, and extended testing.
- Deploy through P2P rather than running production changes manually. P2P builds, validates, promotes, and deploys the approved production candidate.
- Use automated production deployment when the team’s change standard allows hands-free delivery through completed P2P stages.
- Use manual production approval when the team requires an explicit release decision before production.
This means application teams can use the PR, CODEOWNERS review, P2P validation stages, and P2P workflow runs as the change-management record for applications deployed on Core Platform.
Your Change Management Evidence
For each application change, retain links to the evidence below. A PR can act as the evidence hub by linking to the related issue, workflow runs, deployment version, and follow-up notes.
- Change request: the PR description and any linked issue, incident, or request.
- Approval routing: the CODEOWNERS entry that selected the reviewers for the changed area.
- Approval record: PR review history and required approval status.
- Validation record: P2P functional testing, stubbed functional testing, integration testing, and extended testing results.
- Deployment record: P2P build, promotion, and production workflow runs.
Shared Responsibilities
Core Platform provides the application delivery workflow, approval routing pattern, deployment audit trail, and standard control points.
Application teams using Core Platform can complete the change-management record by:
- Keeping PR descriptions clear enough for change review.
- Maintaining CODEOWNERS coverage for their repository.
- Choosing the required P2P stages for their delivery risk.
- Deciding which delivery units can be fully automated and when they must have a manual gate.
- Retaining links between PRs, workflow runs, deployment versions, and follow-up notes.
SOC 2 And ISO 27001 Mapping
| Control | Description | Framework Mapping |
|---|---|---|
| CHG-4 | Change management | ISO 27001:2013 A.12.1.2 |
| SEA-4 | Secure system engineering principles | ISO 27001:2013 A.14.2.5 |
| TDA-7 | Secure development policy | ISO 27001:2013 A.14.2.1 |
| CHG-39 | Change management | ISO 27001:2022 A.8.32 |
| IAC-204 | Use of privileged utility programs | ISO 27001:2022 A.8.18 |