In-scope personnel are people whose job duties give them access to sensitive data, critical systems, or protected environments. The term usually includes employees, contractors, administrators, and other high-risk roles. Defining the scope correctly is important because screening controls and audit evidence depend on who is included.
Expanded Definition
In-scope personnel are the people an organisation designates as subject to security screening, monitoring, access governance, and audit evidence requirements because their duties can affect sensitive data or protected environments. In NHI security, the term matters because humans often approve, manage, rotate, or recover non-human identities, secrets, and privileged automations. Definitions vary across vendors and programmes, but the operational idea is consistent: the scope should include roles with elevated trust, elevated access, or meaningful control over production systems, credentials, or identity workflows. That makes the term adjacent to insider-risk, privileged access management, and joiner-mover-leaver controls, but it is not the same as general workforce population management. The practical boundary should be documented so screening, training, approval workflows, and evidence collection are applied consistently across employees, contractors, administrators, and other high-risk functions. For standards-oriented guidance on identity assurance and access control, organisations often align this scoping with OWASP Non-Human Identity Top 10 and related identity governance practices. The most common misapplication is treating all staff as in scope, which occurs when teams fail to distinguish between routine users and personnel who can directly expose secrets or alter privileged automation.
Examples and Use Cases
Implementing in-scope personnel rigorously often introduces extra review and evidence-collection overhead, requiring organisations to weigh stronger control assurance against slower onboarding and more administrative coordination.
- Cloud administrators who can create service accounts, approve secret rotation, or modify vault policies are in scope because they can directly influence NHI exposure.
- Contractors building CI/CD pipelines may be in scope if they can embed API keys, alter deployment workflows, or access production logs that contain credentials.
- Security engineers managing PAM and JIT workflows are in scope because they govern who can reach privileged systems and when access is granted.
- Platform operators responsible for offboarding tokens and certificates are in scope because delayed revocation can leave valid secrets active after role changes.
- Program managers overseeing identity exceptions may be in scope if they approve risk acceptances tied to service accounts or protected environments.
For examples of how poor human oversight can amplify NHI exposure, review Ultimate Guide to NHIs — Key Challenges and Risks alongside the OWASP Non-Human Identity Top 10. In practice, teams often map in-scope personnel by role, by system access, and by ability to influence secrets handling, rather than by job title alone.
Why It Matters in NHI Security
In-scope personnel determines where governance controls begin and where audit evidence must be retained. If the scope is too narrow, screening gaps leave privileged operators, developers, and contractors outside oversight even though they can create, expose, or fail to revoke secrets. If the scope is too broad, organisations waste time on low-risk roles and dilute attention from the people most likely to affect service accounts, API keys, certificates, and automation pipelines. NHIMG research shows that 97% of NHIs carry excessive privileges, which means the humans who administer them become critical control points for reducing blast radius and preventing misuse. That is why scoping must support access review, segregation of duties, and documented approval paths, not just HR compliance. A useful operational lens is the NHI lifecycle, especially when personnel changes affect offboarding and rotation obligations. The related incident pattern appears in Microsoft SAS Key Breach and Replit AI Tool Database Deletion, where human access and automation decisions intersected with high-impact outcomes. Organisations typically encounter the consequences of mis-scoped personnel only after a leaked secret, privileged misuse, or failed offboarding event, at which point the term 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 CSA MAESTRO 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-01 | Personnel scope affects who can create, manage, or expose non-human identities. |
| NIST CSF 2.0 | PR.AA-01 | Identity and access management depends on correctly defining who is subject to control. |
| NIST SP 800-63 | AAL2 | Assurance expectations rise for personnel handling sensitive identity operations. |
| NIST Zero Trust (SP 800-207) | Zero trust relies on continuously evaluating trusted operators and their access context. | |
| CSA MAESTRO | Agentic governance depends on human operators who approve, monitor, and override automation. |
Require stronger authentication and verification for personnel with privileged identity duties.
Related resources from NHI Mgmt Group
- How should security teams handle leaked credentials reported outside bug bounty scope?
- What is the difference between OAuth scope inventory and scope monitoring?
- What is the difference between scope-based authorization and object-level authorization in MCP?
- What is the difference between client identity and permission scope in MCP governance?
