DEV-03 Policies for changes to information systems
Publish change management rules for software deployment setting criteria for risk categorisation, the testing and approvals each category demands, separation between developing, testing and releasing, customer notificati
4
artefacts
0
held by a system
0
at each review
hard
to go live
Policy repository / GRC workspace
where the evidence lives
teal = a system already holds it · olive = produced at each review
system holds itEvidence a system already holds
none for this control
periodic reviewEvidence produced at each review
none for this control
governing documentDocuments that govern the control
- Change management rules stating risk categories with the matching test and approval levels · Policy repository / GRC workspace
- Definition of how developing, testing and releasing duties are held apart · Policy repository / GRC workspace
- Requirement text for informing customers about changes that affect them · Policy repository / GRC workspace
- Emergency change instruction including its retrospective documentation obligation · Policy repository / GRC workspace
First move
This control is evidenced by people and documents, not systems. Put the document under version control with an owner and review date, and log each review as a record with reviewer and date. Do not try to automate it.
Common gaps auditors find
- The emergency route is used routinely, sidestepping the approvals the rules set out
- A single engineer is permitted to build, test and release the same change
- Rules omit any obligation to refresh system, operational and user documentation
Do this for your whole sheet
Paste the rows you run your controls from and get this mapping for every control at once, with the periodic-review ones flagged and a first move per row. No account for the first run.
Build my evidence sheetDEV-02 Outsourcing of the development · DEV-04 Safety training and awareness programme regarding continuous software delivery and associated systems, components or tools