Compliance
Prove every production change was authorized. All of them, not a sample.
Auditors ask the same question in every framework: was this change requested, approved, tested and made by someone allowed to make it? Nakana answers it for every change, as it happens, with the evidence attached.
No more sampling
Every change in scope has a record: what, who, when, why and the verdict. Auditors can test the whole population or pick their own sample from it.
Fix it before the audit
Changes with no reason are flagged the day they happen. The person who made them is asked, and a retroactive change request is opened if needed.
Evidence in the format they want
Change population reports by system and period, with linked tickets, approvals, commits and pipeline runs, as CSV or PDF, or written back to ServiceNow.
Control mapping
Where Nakana's records fit
Nakana provides evidence for these controls. It doesn't make you compliant on its own, and your auditor decides what's sufficient.
| Framework | Controls | What Nakana provides |
|---|---|---|
| SOX ITGC | Program change management; access to programs and data | Every change to in-scope systems linked to its request, approval, test evidence and deployer. Segregation-of-duties check: author, approver and deployer are different people. Privileged changes outside the process flagged. |
| PCI DSS 4.0.1 | 1.2.2, 6.5.1–6.5.6, 10.2, 10.4, 11.5.2 | Network security control changes tied to approved requests. Change records with reason, approval and impact. Audit trail of privileged actions, reviewed daily by exception. Change detection on critical files, with each change explained. |
| SOC 2 | CC8.1, CC7.1, CC7.2, CC6.1–CC6.3 | Changes authorized, approved and implemented through the process, evidenced continuously. Configuration changes monitored. Anomalous access and privileged activity detected. |
| ISO/IEC 27001:2022 | Annex A 8.32, 8.9, 8.15, 8.16, 8.2 | Change management, configuration management, logging and monitoring evidence. Use of privileged access rights recorded and reviewed. |
| HIPAA Security Rule | §164.308(a)(1)(ii)(D), §164.312(b), §164.312(c)(1) | Information system activity review, audit controls and integrity evidence for systems that hold ePHI. |
| NIST SP 800-53 Rev. 5 | CM-3, CM-5, CM-6, AU-6, AC-6(9), SI-7 | Configuration change control and access restrictions for change, audit review, logging of privileged functions and integrity monitoring. |
| DORA | Art. 9 and the ICT risk management RTS | ICT change management records for financial entities: every change recorded, assessed, approved and traceable to a person. |
| NIS2 | Art. 21(2) and Implementing Regulation (EU) 2024/2690 | Change management and logging evidence for essential and important entities. |
What an auditor sees
One record per change
The same record works for the auditor, the security team and the engineer who made the change.
Have an audit coming?
Design partners with a SOX, PCI DSS or SOC 2 audit in the next two quarters get priority.