They need both sets of details because identity risk is shared across the party requesting the work and the environment being assessed. Requestor details support accountability, while customer details define ownership, scope, and contact paths. Without that separation, teams can misroute findings, delay scheduling, or lose traceability for remediation decisions.
Why This Matters for Security Teams
Identity vulnerability assessments often fail before the first control is tested because the intake data is incomplete. Requestor details establish who initiated the work, who approved it, and where accountability sits if findings need escalation. Customer details define the environment, asset owner, and remediation contact path. Without both, assessments can be scheduled against the wrong scope, findings can stall in handoff, and traceability for risk decisions breaks down.
This distinction matters because identity risk is rarely isolated to one team. Non-human identities, service accounts, API keys, and AI workloads often cross organisational boundaries, which makes ownership as important as technical exposure. NHIMG research on 52 NHI Breaches Analysis shows how frequently secret misuse and weak accountability appear together, while the broader Ultimate Guide to NHIs frames why identity records must map to both people and systems. In practice, many security teams encounter this only after a finding is disputed, delayed, or reassigned multiple times rather than through intentional intake design.
How It Works in Practice
A sound assessment intake separates two layers of context. The requestor is the party asking for the assessment, sponsoring the work, or authorising access to the scope. The customer is the party that owns the environment, receives the results, and is responsible for remediation. This is a governance pattern, not a formality, and it aligns with least-privilege thinking in CIS Controls v8 and threat-driven prioritisation in ENISA Threat Landscape.
Operationally, teams use requestor details to validate legitimacy, approval chain, and communication rights. Customer details are then used to define scope boundaries, system owners, business impact, and escalation contacts. That split helps prevent three common failures:
- Findings routed to a sponsor who cannot remediate them.
- Assessments launched without the actual asset owner’s awareness.
- Evidence retained without a clear decision-maker for risk acceptance.
The same model becomes more important when assessing credentials tied to machine identities, API integrations, or agentic workflows. A request may come from a platform team, but the customer may be a product owner, workload owner, or security office with different responsibilities. NHIMG’s Top 10 NHI Issues highlights how ownership ambiguity and stale access records routinely complicate remediation. Current guidance suggests intake should capture both parties at the start, then link them to the ticket, report distribution list, and exception workflow. These controls tend to break down when a central security team books assessments for many business units because the wrong contact data is often copied forward from an older engagement.
Common Variations and Edge Cases
Tighter intake controls often increase administrative overhead, requiring organisations to balance cleaner accountability against faster scheduling. That tradeoff is real, especially in shared-service environments where one team requests the assessment and another team owns the application, cloud tenant, or secrets store.
There is no universal standard for this yet, but best practice is evolving toward explicit role separation. For example, the requestor may be a security engineer, procurement lead, or partner manager, while the customer may be the internal application owner or an external tenant administrator. In third-party assessments, both fields help distinguish the buyer from the assessed party, which is critical when contractual notice, evidence handling, or remediation deadlines differ.
Edge cases also appear in incident-driven assessments. If a secret exposure, compromised service account, or AI agent credential issue is urgent, the requestor may be a responder while the customer is the affected system owner. That separation helps preserve chain of custody and avoids sending sensitive findings to the wrong mailbox. NHIMG’s DeepSeek breach and the JetBrains GitHub plugin token exposure are useful reminders that identity events spread quickly once ownership is unclear, so the intake process must be precise even when the assessment timeline is compressed.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Identity intake must tie NHI activity to clear ownership and scope. |
| OWASP Agentic AI Top 10 | A-03 | Agentic and machine identities need runtime accountability and context. |
| CSA MAESTRO | GOV-2 | MAESTRO emphasises governance and ownership for autonomous workloads. |
| NIST AI RMF | GOVERN | AI RMF governance requires clear accountability for decisions and impacts. |
| NIST CSF 2.0 | PR.AC-1 | Access governance depends on knowing who is authorised and responsible. |
Define governance contacts separately from environment owners for every assessment engagement.
Related resources from NHI Mgmt Group
- Why do customer identity programmes still need advisory services even when the platform is strong?
- What is the difference between patching a vulnerability and reducing identity blast radius?
- Who should own policy for digital credential acceptance in a customer identity programme?
- How should organisations evaluate identity governance programmes when they need both compliance control and measurable cost reduction?
