Who is accountable when customer security settings drift out of compliance?

Why This Matters for Security Teams

When customer security settings drift out of compliance, the real risk is not the drift itself but the lack of clear operational ownership for detecting, approving, and correcting it. NIST treats this as a governance and continuous monitoring problem, not a one-time configuration task, and the same logic applies in MSP-run environments and internal platforms. The accountable party is usually the operator that can observe state, enforce baselines, and remediate deviations, while the vendor remains accountable for product defects and supported controls.

That distinction matters because compliance evidence often depends on live configuration state, not design intent. If teams do not define who owns baseline management, alert triage, escalation, and restoration, drift becomes a shared problem that no one owns. NHIMG guidance on Ultimate Guide to NHIs — Regulatory and Audit Perspectives and NIST Cybersecurity Framework 2.0 both point to accountability as an operating control, not a paperwork exercise. In practice, many security teams discover this only after an audit exception or incident has already exposed the gap.

How It Works in Practice

Accountability should be assigned by control plane, not by assumption. The operator of the environment is typically responsible for enforcing secure baselines, monitoring drift, and acting on exceptions, because that party has the telemetry, permissions, and change-management access needed to fix the issue. The vendor’s responsibility is different: product security, documentation, safe defaults, and timely patching. NIST SP 800-53 Rev. 5 Security and Privacy Controls supports this split by emphasizing continuous assessment, configuration management, and accountability for control execution.

In practical terms, mature teams define a named owner for each of the following:

• baseline policy and approved exceptions
• continuous monitoring and alert thresholds
• remediation timelines and rollback authority
• escalation when drift affects customer risk or regulatory exposure
• evidence retention for audit and incident response

That operating model should also be tied to the customer contract or shared-responsibility statement, especially for managed services. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because drift often reflects lifecycle failure: weak provisioning, missed rotation, or untracked changes. Where customers connect through apps or automation, the control burden grows quickly, and visibility gaps can become the actual cause of noncompliance. The guidance breaks down when customer environments are highly federated and multiple teams can change the same settings because attribution and remediation authority become ambiguous.

Common Variations and Edge Cases

Tighter accountability often increases operational overhead, requiring organisations to balance faster remediation against the cost of deeper monitoring and approval workflows. That tradeoff is especially visible in MSP models, co-managed security programs, and regulated environments where the customer retains policy authority but the provider executes changes. Best practice is evolving, but current guidance suggests the accountable operator must still be able to prove who approved the state, who detected the drift, and who restored compliance.

Edge cases usually come down to control ownership across shared systems. If a customer changes a security setting through its own admin console, the customer may own the decision, but the operator may still own detection and notification. If drift results from a product defect, the vendor may own the defect remediation, yet the operator still owns risk handling until the fix is applied. For that reason, contracts should separate product liability from operational accountability and include explicit evidence obligations.

NHIMG’s coverage of the Salesloft OAuth token breach is a reminder that configuration drift and token misuse often appear together, which is why ownership must extend beyond static settings into monitoring of connected identities. Current governance frameworks such as ISO/IEC 27001:2022 Information Security Management expect clear responsibility for control effectiveness, even when execution is delegated. If accountability is not written into the operating model, drift will usually be discovered by auditors, customers, or attackers before it is found internally.

Related resources from NHI Mgmt Group

• Who is accountable when an organisation accepts mediocre identity security and later suffers preventable risk or compliance issues?
• Who is accountable when access paths outside IAM and SSO create compliance or security gaps?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities for SOC 2 compliance?