A government contract document that defines how performance will be monitored and accepted. For identity programmes, it turns service expectations into observable criteria, so a vendor support team that cannot read it is unlikely to operate effectively inside the customer's governance process.
Expanded Definition
A Quality Assurance Surveillance Plan, often shortened to QASP, is the contract-level mechanism that turns service expectations into measurable surveillance criteria. In NHI and agentic AI environments, that matters because the work being monitored is usually ongoing access, credential handling, logging, rotation, and support response rather than a one-time deliverable. The plan tells the customer what to observe, how to sample it, and what constitutes acceptable performance.
Definitions vary across vendors and procurement teams, but the operational purpose is consistent: a QASP creates evidence-based accountability for the party operating inside the customer’s governance process. That makes it distinct from an SLA, which states the service promise, and from technical controls, which implement security requirements. A QASP is the oversight layer that checks whether the service actually behaves as contracted, including handling of secrets, escalation paths, and remediation timing. For identity-heavy services, that oversight should align with NIST SP 800-63 Digital Identity Guidelines where identity assurance and verifier obligations are relevant. The most common misapplication is treating the QASP as a procurement appendix that is never operationalised, which occurs when surveillance criteria are written but not tied to real review cadence or acceptance thresholds.
Examples and Use Cases
Implementing a QASP rigorously often introduces review overhead and evidence-collection burden, requiring organisations to weigh stronger accountability against slower administration.
- A managed service provider rotating API keys for a customer-facing integration is sampled weekly to confirm the rotation interval, evidence retention, and approval trail.
- A vendor running privileged support for service accounts is assessed against ticket response times, escalation rules, and whether access is revoked after the task is complete, a pattern that should be read alongside the Ultimate Guide to NHIs.
- A government programme requires monthly surveillance reports for credential storage, logging completeness, and exceptions handling when secrets are moved between systems.
- A platform team uses the QASP to verify that a contractor’s operational support matches the identity proofing and lifecycle expectations described in NIST SP 800-63 Digital Identity Guidelines.
- An AI operations contract includes surveillance of agent tool access, command approval, and incident response evidence to show the provider is not exceeding delegated authority.
In practice, the QASP is most useful when the customer needs to prove that controls are not only written down but also being performed consistently over time.
Why It Matters in NHI Security
QASPs matter in NHI security because the highest-risk failures are often operational, not theoretical. A service can appear compliant on paper while leaving secrets unrotated, support access overbroad, or offboarding incomplete. NHIMG research shows that 97% of NHIs carry excessive privileges, and only 20% have formal processes for offboarding and revoking API keys, which means surveillance criteria are often the only way a customer can detect whether a provider is actually reducing exposure. The Ultimate Guide to NHIs also highlights how frequently organisations lose visibility into service accounts, making contractual observability a governance necessity rather than a paperwork exercise.
A well-written QASP gives procurement, security, and audit teams a common language for evidence, sampling, exceptions, and remediation. It becomes especially important when third parties handle credentials, tokens, or privileged support paths that sit outside direct internal tooling. Without it, the customer may not know whether a control failed until after a compromise, a missed rotation, or a broken offboarding event. Organisations typically encounter the need for a QASP only after a vendor incident or audit finding exposes that performance was assumed, not verified, at which point the concept 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 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-1 | QASPs operationalize supplier oversight and service verification in governance. |
| OWASP Non-Human Identity Top 10 | NHI-06 | Vendor-operated NHI services must be observable to prevent privilege and lifecycle failures. |
| NIST Zero Trust (SP 800-207) | 3.1 | Continuous verification and policy enforcement align with QASP surveillance intent. |
| NIST SP 800-63 | IAL2 | Where identity assurance and verification obligations apply, QASPs can test compliance. |
Define surveillance criteria and review evidence for third-party service performance on a recurring schedule.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
