DEV-05 Risk assessment, categorisation and prioritisation of changes
Assess each planned change for its potential effect on the system components involved and assign it a risk category and priority, which then determine how deeply it is tested and what approvals it must carry.
4
artefacts
0
held by a system
1
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
- Risk assessment entry attached to each of a sample of changes · Ticketing / ITSM
governing documentDocuments that govern the control
- Category and priority definitions applied to changes · Policy repository / GRC workspace
- Trace showing the assigned category actually drove testing depth and approval level · Policy repository / GRC workspace
- Advance information sent to customers ahead of top-category changes · 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
- Every change assigned the same category regardless of its likely impact
- The assessment is completed after deployment purely to satisfy the record
- Top-category changes released without the advance customer information the contract requires
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-04 Safety training and awareness programme regarding continuous software delivery and associated systems, components or tools · DEV-06 Testing changes