For change management, auditors tend to ask the same few things: who approved this release, what was tested, when did it deploy, and what happened to the emergency changes. The evidence is far easier to capture at the decision than to rebuild afterwards.
Auditors reviewing change management typically want to see, for a sample of releases, who requested and approved each change, what was tested and with what result, when it was deployed and by whom, whether anyone with a conflict of interest approved their own work, and how emergency changes were reviewed after the fact. Frameworks such as SOC 2 (its change-management criteria) and SOX IT general controls ask for this kind of evidence.
Evidence reconstructed before an audit from chat history, screenshots and memory is slow, partial and easy to challenge. Approvals given as chat messages can be edited or deleted, and are hard to find again. The record needs to be made at the time, by the process, not by whoever is on duty the week before the audit.
Shipping past a failing check, or shipping an emergency fix, will happen. Auditors do not expect it never to; they expect it to be visible, justified and reviewed. A signed statement with a reason and evidence, kept with the release, answers the question before it is asked.
ArcRelease records each gate, owner and sign-off as evidence at the moment of the decision. Shipping past a failing check requires an admin or release manager to sign a statement and attach evidence, and the preflight is snapshotted at that moment. The audit log is append-only: the database blocks updates and deletes. A SOC 2 evidence report can be generated from the live data. This helps you evidence your own controls; it is not a certification of your organisation, and ArcRelease does not hold a SOC 2 Type II report.
Typically, for a sample of changes: the request and approval, the testing done and its result, the deployment record, confirmation that duties were separated, and the review of any emergency changes. The exact list depends on the framework and the auditor.
A change that has to ship outside the normal flow because waiting would cost more, for example a fix to a live outage. It is normally allowed, with a named approver, and reviewed after the fact, and the record of both is what auditors look for.
They can be edited or deleted, they are hard to retrieve for a given release, and they rarely link to the change itself. An approval an auditor can verify is recorded by the process, tied to the release, and cannot be changed afterwards.
The principle that the person who writes a change should not be the only person who approves or deploys it. Evidence shows that a second person reviewed or approved it.
As long as your policy and the frameworks you are held to require. That varies, so check with your compliance team; the point for tooling is that records must not be lost or altered inside that period.
No tool does that by itself. ArcRelease captures the change-management evidence and can generate a SOC 2 evidence report from it, which helps you show your own controls to your auditor. The compliance decision is the auditor's.
Tell us about your release process. Connect your stack in ten minutes, run a Gaja preflight on a real release, and see the reasons behind the verdict.
Free plan · ten minute setup · we reply in one to two business days