Change management
Change records your auditor can follow
Auditors test change control by picking a sample of changes and asking who requested, approved and tested each one. In Certifyi that evidence sits on the controls it supports, and you can create Jira tickets from failing controls, so your engineers keep working in their own tools.
In short
Auditors test change control by sampling changes and checking that each one was requested, assessed, approved, tested and reviewed. Certifyi does not replace Jira or ServiceNow. You create Jira tickets from failing controls and attach change evidence to the control it supports, and when the auditor asks who touched that evidence, the tamper-evident activity log answers.
What each change record should show
Whichever tool holds your changes, an auditor sampling them will look for the same things.
- What and why. What is changing, the reason and who asked for it.
- Type. Standard, normal or emergency, which decides the approval path.
- Impact. The systems and services affected and the risk of the change going wrong.
- Approval. Who approved it, when, and any conditions attached.
- Window and rollback. When it will be made, and how to undo it.
- Testing and review. Evidence it was tested, and a short review once it is live.
Approval by change type
Most change processes, including ITIL, use three change types. Low-risk, repeatable changes follow a pre-approved procedure. Everything else is assessed and approved individually, and emergencies go ahead first and are documented straight afterwards.
- Standard change
- Pre-approved, low risk and repeatable, following a written procedure. For example, a routine patch to a test environment.
- Normal change
- Assessed and approved one at a time. Most infrastructure and application changes are normal changes.
- Emergency change
- Made urgently, outside the normal queue. It must be documented and reviewed within an agreed time afterwards.
Jira tickets from failing controls
A failing control is often the first sign that a change went wrong. From the control in Certifyi you can create a Jira ticket, and the fix joins the normal engineering queue. If your changes run through ServiceNow, keep them there and attach the change evidence to the control it supports.
Change records as audit evidence
ISO 27001 Annex A 8.32, SOC 2 CC8.1, PCI DSS Requirement 6.5.1 and NIST SP 800-53 CM-3 all ask for evidence that changes follow a defined process. In Certifyi you attach that evidence (ticket exports, approval records, post-implementation reviews) to the control it supports, and anything done to that evidence afterwards is written to the tamper-evident activity log. If you answer to more than one of them, map the control once and reuse the mapping, and the same change evidence serves them all.
When fieldwork starts, the auditor gets scoped, read-only access to the evidence for their engagement and can pick the sample there, without waiting for you to export it.
Changes that touch your controls
A change to a firewall rule, a database schema or an access policy is also a change to your control environment. Agree in advance which systems need a compliance check before changes go live, and add that check to the approval step for those systems only.
A compliance gate on every deployment slows engineering down, and before long people start working round it.
Common audit findings in change management
Most of these come down to a missing record, and each is simple to prevent.
-
Approved after the fact
The approval date is later than the deployment date. Record approval before the change window opens.
-
Emergency changes left open
The change went in fast and nobody documented it afterwards. Set a deadline for the review and check it is met.
-
No test evidence
The ticket says “tested” with nothing attached. Keep the test result with the change.
-
Self-approval
The person who made the change also approved it. Auditors look for separation of duties.
Related modules
Change records relate to the assets being changed, the patches being applied and the controls that rely on them.
How Certifyi helps
How Certifyi fits your change process
Keep Jira or ServiceNow for the work itself. Certifyi holds the compliance record around it.
-
Jira tickets
Create Jira tickets from failing controls.
-
Evidence beside the control
Attach change evidence to the control it supports.
-
Activity log
Each action on change evidence is written to the tamper-evident activity log.
-
Auditor access
The auditor sampling your changes gets scoped, read-only access to the evidence for their engagement.
Questions
Change management questions
Does this replace Jira or ServiceNow?
No. Your engineers keep working in their ticketing tool. From a failing control in Certifyi you create a Jira ticket, and Certifyi holds the evidence your auditor needs.
What is the difference between standard, normal and emergency changes?
Standard changes are low risk, repeatable and pre-approved. Normal changes are assessed and approved one at a time. Emergency changes go ahead urgently and are documented and reviewed afterwards.
How should we handle emergency changes?
Let them skip the approval queue, but require a record within an agreed time afterwards: the justification, the impact assessment and a post-implementation review. Auditors will want to see both the change and the follow-up.
Which frameworks ask for change management evidence?
ISO 27001 Annex A 8.32, SOC 2 CC8.1, PCI DSS Requirement 6.5.1 and NIST SP 800-53 CM-3 all expect evidence that changes follow a defined process.
Make change control easy to evidence
Think of the last change an auditor sampled and how long the evidence took to gather. Book a demo and we will trace a change like it through Certifyi, from the Jira ticket to the evidence on the control to the read-only view the auditor works in.
- Each customer workspace has its own database
- Every change written to a tamper-evident activity log
- Auditors get scoped, read-only access
- AI suggestions wait for a person to accept them