Accountability sits with the organisation that owns the application and its change management controls. Security, engineering, and compliance teams must define who reviews material changes, who approves risk decisions, and what evidence is retained. In regulated environments, auditors expect a repeatable process, not informal judgement or post hoc explanations.
Why This Matters for Security Teams
Material software changes are not just an engineering concern when the application handles regulated data, invokes privileged non-human identities, or alters control behaviour. The accountability question sits at the intersection of change management, access governance, and evidence retention. Current guidance from NIST Cybersecurity Framework 2.0 and ISO/IEC 27001:2022 Information Security Management treats change control as an organisational responsibility, not an individual one, because the risk is created by the process that allows a change to reach production.
NHI Management Group research shows the risk is often amplified by weak lifecycle discipline: 71% of NHIs are not rotated within recommended time frames, and 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. That means a “small” software update can silently change how secrets are read, where data is sent, or which identity can reach a regulated system. For audit purposes, the important question is not who typed the change, but who had authority to approve it, who validated the compliance impact, and what evidence proves that review happened. In practice, many security teams encounter this only after a release has already altered regulated data handling or widened access paths.
How It Works in Practice
Accountability is usually shared operationally, but it must be clearly assigned in policy. The application owner typically remains accountable for the change, engineering is responsible for implementing it, security for assessing identity and control impact, and compliance or risk for confirming whether the change affects regulatory obligations. That model aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls, which expects organisations to control system changes, preserve audit evidence, and manage access to sensitive functions.
In regulated environments, a material change review should ask whether the software update changes:
- which data is collected, stored, transmitted, or deleted
- which NHIs, service accounts, or APIs can access that data
- the approval path for privileged actions or exception handling
- logging, retention, masking, encryption, or cross-border handling
- dependencies that may alter downstream compliance behaviour
For NHI-heavy applications, the safest practice is to treat credential scope and data handling as change-managed artefacts. That includes reviewing secrets rotation, token lifetime, new outbound destinations, and any changes to tool access or automated workflows. NHIMG guidance on Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Ultimate Guide to NHIs — Regulatory and Audit Perspectives emphasises that lifecycle controls and auditability must move together, especially where secrets, service accounts, and regulated data intersect. A defensible workflow uses pre-approval criteria, documented risk acceptance, and post-change verification with retained evidence. These controls tend to break down when release pipelines auto-deploy configuration changes into regulated environments without a human review step for data-handling or identity-impacting changes.
Common Variations and Edge Cases
Tighter change controls often increase release latency and review overhead, requiring organisations to balance delivery speed against evidentiary certainty. That tradeoff is real, especially when software changes are frequent and the compliance impact is not obvious at commit time.
Current guidance suggests three common edge cases need special handling. First, in CI/CD-heavy environments, accountability should extend to pipeline owners because a build or deployment rule can change compliance behaviour without changing application code. Second, when a vendor manages part of the stack, the organisation still retains accountability for the control outcome, even if execution is outsourced. Third, if an AI agent or automation tool can modify configuration, create secrets, or route regulated data, its actions should be reviewed under the same change governance as a human operator.
This is where NHI evidence matters. NHIMG’s Ultimate Guide to NHIs — Key Research and Survey Results shows how common weak NHI hygiene is in practice, which makes post-change assurance harder than teams often expect. For organisations adopting a formal accountability model, the practical standard is to define who approves materiality, who signs off on compliance impact, and who owns the evidence archive. There is no universal standard for this yet, but best practice is evolving toward explicit approval matrices, immutable change records, and periodic control testing tied to NIST SP 800-63 Digital Identity Guidelines and the organisation’s own risk register.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC, PR.IP | Clarifies governance ownership and change control for regulated systems. |
| NIST SP 800-53 Rev 5 | CM-3, CM-5, AU-2 | Change control and audit logging are central to proving compliance impact reviews. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Material changes often alter service-account or secret exposure and ownership. |
| NIST AI RMF | GOVERN | Autonomous or AI-assisted changes need clear accountability and oversight. |
| CSA MAESTRO | GOV-01 | Agentic workflows can modify systems and must be governed like operational actors. |
Treat agent-driven changes as controlled operations with explicit approval, traceability, and rollback plans.
Related resources from NHI Mgmt Group
- Who should be accountable for SAP financial configuration changes that affect general ledger, accounts payable, and integration postings?
- Who is accountable for security and compliance when SAP data is moved into a new environment?
- Who is accountable for keeping RBAC aligned with job changes and compliance requirements?
- Who is accountable for compliance when managed gateways process regulated API traffic?
