Relationship context is the surrounding knowledge that helps a person judge whether a request is normal, expected, and properly authorised. In email security, it includes who usually communicates with whom, how often they interact, and whether the timing and format match past behaviour. Without it, routine-looking fraud becomes much harder to spot.
Expanded Definition
Relationship context is the behavioural and organisational backdrop that helps security teams decide whether a request, message, or action fits expected business reality. It goes beyond content inspection and looks at communication patterns, trust paths, role relationships, timing, channel consistency, and the history of interaction between parties. In email and collaboration platforms, this means understanding whether the sender normally contacts the recipient, whether the format matches prior exchanges, and whether the request aligns with the relationship that actually exists. That makes it a practical control concept for fraud detection, impersonation resistance, and suspicious request triage.
In security operations, relationship context is often used as a signal rather than a standalone verdict. It strengthens decisions made by detection tooling, analyst review, and workflow approvals, especially when an adversary tries to exploit familiarity or urgency. This idea aligns with the broader risk-based approach described in the NIST Cybersecurity Framework 2.0, where organisations are expected to understand assets, relationships, and business dependencies well enough to make defensible security decisions.
Definitions vary across vendors because some tools use relationship context to mean historical communication graphs, while others include identity attributes, delegated authority, and workflow provenance. NHI Management Group treats the term more narrowly: it is the evidence that a request is plausible because the relationship, not just the message, makes sense. The most common misapplication is treating a known sender address as sufficient proof of legitimacy, which occurs when attackers hijack a trusted mailbox or mimic an existing relationship with convincing but abnormal timing.
Examples and Use Cases
Implementing relationship context rigorously often introduces visibility and data-processing overhead, requiring organisations to weigh stronger fraud detection against privacy, tuning, and maintenance cost.
- A finance team receives a payment-change request from a supplier contact. Relationship context checks whether that contact has historically used that channel, that tone, and that approval path before the request is accepted.
- An executive assistant gets a last-minute wire transfer email. The system flags the request because the sender, timing, and urgency do not match the normal relationship history, even though the message appears professionally written.
- A help desk receives an account-reset request from an employee’s manager. Relationship context verifies whether managers normally initiate such requests, whether the request fits the team workflow, and whether a separate approval step is required.
- In collaboration tools, an internal user asks for a document from a teammate they rarely interact with. The security review looks at prior interaction patterns and whether the request aligns with project context or resembles social engineering.
- For higher-assurance workflows, relationship context may be combined with identity verification signals and policy logic from sources such as NIST Cybersecurity Framework 2.0 to reduce false approvals without blocking legitimate work.
Why It Matters for Security Teams
Relationship context matters because many attacks succeed by imitating normal business behaviour rather than breaking technical controls. When teams only inspect the sender, subject line, or signature, they miss the broader pattern that shows whether the request fits the organisation’s real operating model. This is especially important in email compromise, invoice fraud, and help desk manipulation, where the adversary tries to borrow trust from an existing relationship. In identity-heavy environments, relationship context also improves decisions around delegated authority, non-human identities, and automated workflows, because a machine account or agent may be technically valid but still inappropriate for the request being made.
It also helps analysts reduce noise. A request can be unusual without being malicious, and a malicious request can look ordinary in isolation. Relationship context gives incident responders and reviewers a way to separate those cases using evidence about who should be talking to whom, through which channel, and under what conditions. The concept is strongest when paired with policy, identity assurance, and behavioural baselines rather than used as a vague intuition test. Organisations typically encounter the cost of missing relationship context only after an approved request turns into fraud, 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 address the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.1 | CSF 2.0 governance emphasizes understanding risk and business relationships. |
| NIST SP 800-63 | IAL2 | Identity assurance supports confidence in who is involved in a relationship. |
| OWASP Non-Human Identity Top 10 | NHI guidance highlights contextual trust around automated identities and agents. |
Map communication and approval paths to governance so abnormal requests are reviewable against expected relationships.