A task or control that remains with the buyer even when the SaaS vendor provides the underlying service. These obligations often include contract acceptance, privacy configuration, access governance, and handling regulated data in a way that matches the vendor’s assurance model.
Expanded Definition
Customer-side compliance obligation describes the part of a security, privacy, or regulatory duty that does not transfer to the SaaS provider just because the service is outsourced. The vendor may supply infrastructure, logging, encryption features, or attestations, but the customer still has to decide how the service is configured, who can access it, what data is stored, and whether its use matches internal policy and external law.
In NHI and IAM operations, this term matters because service accounts, API keys, automation tokens, and delegated workflows often sit inside systems the buyer administers only partially. That makes the obligation easy to miss. Guidance varies across vendors on where shared responsibility ends, so teams should treat the contract, architecture, and control map as separate artifacts rather than assuming a platform badge equals compliance. NIST’s NIST Cybersecurity Framework 2.0 is useful here because it reinforces that governance and risk decisions remain operational responsibilities, not vendor side effects.
The most common misapplication is assuming the provider’s certifications automatically satisfy customer obligations, which occurs when teams skip data classification and access review before enabling the service.
Examples and Use Cases
Implementing customer-side compliance obligations rigorously often introduces friction in onboarding and administration, requiring organisations to weigh faster SaaS adoption against tighter control over data, access, and evidence collection.
- A procurement team accepts a SaaS contract, but security still must confirm retention terms, breach notification timing, and subprocessors before production use.
- An identity team enables the platform, then must configure role-based access control, MFA, and privileged review for admin consoles and automation identities.
- A compliance owner approves use of regulated data, but the customer must still classify records, restrict exports, and validate regional storage settings.
- A finance workflow uses an API key to post transactions, and the customer must rotate the secret, scope its permissions, and document the control in audit evidence.
- A third-party risk review references Ultimate Guide to NHIs - Regulatory and Audit Perspectives alongside NIST SP 800-53 Rev 5 Security and Privacy Controls to show which controls remain with the customer even when the service is externally hosted.
NHIMG research shows that the vast majority of organisations expose NHIs to third parties, which makes customer-side control decisions a recurring control issue rather than an edge case.
Why It Matters in NHI Security
Customer-side compliance obligations are often where NHI governance fails in practice. When a team assumes the vendor owns the whole risk, secrets are left overprivileged, admin roles are shared, and audit evidence is incomplete. That gap is especially dangerous because NHI incidents usually begin with ordinary operational shortcuts, such as long-lived API keys, undocumented integrations, or unattended service accounts. NHIMG reports that 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, a pattern that directly turns customer-side responsibility into exposure.
This is why vendor assurance has to be translated into customer action. Standards such as ISO/IEC 27001:2022 Information Security Management and ISO/IEC 27002:2022 Information Security Controls support the idea that externally provided services still require internal governance, control selection, and monitoring. The same principle appears in NHIMG guidance on Top 10 NHI Issues, where mismanaged secrets and weak lifecycle controls repeatedly emerge as root causes.
Organisations typically encounter this burden only after an audit finding, access compromise, or data-handling dispute, at which point customer-side compliance obligation becomes operationally unavoidable to address.
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 OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Customer-owned secret handling and access governance sit at the core of NHI-02. |
| NIST CSF 2.0 | GV.RM-01 | This term is fundamentally about governance and risk decisions that stay with the customer. |
| NIST SP 800-63 | AAL2 | Customer-side access control must match assurance needs for administrative and automated identities. |
| NIST Zero Trust (SP 800-207) | PL-01 | Zero Trust assumes continuous policy enforcement even when the service is externally hosted. |
| OWASP Agentic AI Top 10 | AGENT-03 | Agentic workflows often inherit customer compliance duties for tool access and data handling. |
Map shared-responsibility gaps to NHI-02 and verify the customer still controls secrets, access, and lifecycle steps.
Related resources from NHI Mgmt Group
- How should financial institutions balance DORA compliance with customer authentication experience?
- Who is accountable when a portfolio company fails a compliance obligation?
- How do NHI breaches typically impact regulatory compliance?
- What does good NHI governance look like for audit and compliance purposes?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
