When an alert fires on an account or a server, responders need to know within minutes who owns it, which team depends on it and who can approve a containment action, and most organisations hold that answer in three disconnected systems. MITRE D3FEND names the defensive work of building that answer Organization Mapping (D3-OM) and defines it as "Organization mapping identifies and models the people, roles, and groups with an organization and the relations between them." It sits under the Model tactic as a child of Operational Activity Mapping (D3-OAM). This guide explains what D3-OM models, which data sources feed it, how to build and maintain it, how it supports detection, hardening and response, and where it typically breaks. It is written for identity teams, security architects and risk managers who need ownership and reporting lines they can rely on during an incident.
Key takeaways
- It is a model, not a control. D3-OM produces a maintained picture of people, roles, groups and their relations; its value comes from what other techniques and processes do with it.
- D3FEND lists no ATT&CK relations for it. The D3FEND page for D3-OM shows no direct or inferred ATT&CK techniques (checked November 2026), so any threat mapping is a downstream use, not part of the technique.
- HR and the directory are the core sources. The HR system gives the organisational hierarchy and positions; the directory and identity governance tooling give groups and roles; neither alone is enough.
- Non-human identities need a place in the map. Service accounts, workload identities and AI agents have no manager in HR, so the map must attach each one to an accountable person and team.
- Freshness is the hard part. Reorganisations, movers and leavers make an organisation map stale within weeks unless it is driven by the same events that drive provisioning.
D3-OM at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-OM (d3f:OrganizationMapping) |
| Tactic | Model |
| Parent technique | Operational Activity Mapping (D3-OAM) |
| Siblings under D3-OAM | Access Modeling (D3-AM), Operational Dependency Mapping (D3-ODM), Operational Risk Assessment (D3-ORA) |
| D3FEND relations | maps Organization, maps Person, maps Dependency; may-map Operational Activity Plan |
| ATT&CK relations | None listed by D3FEND |
| D3FEND references | OMG Unified Architecture Framework (UAF), a UAF modelling plug-in, and a book on organisational management in an HR system |
| Typical owners | HR systems team, identity and access management, enterprise architecture |
| Main output | A queryable graph of organisational units, positions, people, groups and accountable owners, including owners of non-human identities |
What D3-OM models
The ontology says D3-OM maps three artefacts: Organization, Person and Dependency, and it may map an Operational Activity Plan. In practical terms the model contains four layers.
- Organisational units: legal entities, divisions, departments and teams, with their parent and child relations. Subsidiaries, joint ventures and outsourced functions belong here too, because they change who can approve access and who must be told about an incident.
- Positions and roles: the job or post a person holds, the business role it implies, and any security role such as system owner, data owner, authorising official or incident commander. Positions persist when people change, which is why HR systems model them separately from people.
- People and groups: employees, contractors and other external personnel, with their manager, their team and the directory groups they belong to.
- Relations and dependencies: reports-to, member-of, owns, approves, backs up and depends-on. The Dependency artefact is what connects the organisation model to the activity and system models built by sibling techniques.
D3FEND's references point to two ways of doing this. The OMG Unified Architecture Framework (UAF) is an architecture modelling standard whose viewpoints include Personnel and Resources, and whose resource performers include persons and organisations; version 1.3 is listed by OMG with an April 2026 date. The other reference is organisational management in an ERP HR system, where organisational units, positions and persons are maintained as linked objects. Most security teams will not build a UAF model; they will assemble the map from HR, directory and governance data, and that is the approach this guide follows.
Data sources and what each contributes
| Source | What it gives the model | Typical gaps |
|---|---|---|
| HR system of record | Organisational units, positions, manager, cost centre, employment status, start and end dates | Contractors and suppliers often missing; no non-human identities; security roles rarely recorded |
| Directory and identity provider | Accounts, groups, group nesting, manager and department attributes synchronised from HR | Stale attributes when sync breaks; groups with no owner; nested groups that hide real membership |
| Identity governance (IGA) | Business roles, entitlement owners, approvers, certification history | Only covers onboarded applications |
| SCIM provisioning feeds | The Enterprise User extension carries employeeNumber, costCenter, organization, division, department and a manager attribute that RFC 7643 describes as optionally allowing service providers to represent organisational hierarchy | Only as good as the upstream source; many applications ignore the extension |
| CMDB and service catalogue | System owners, support groups, business service owners | Owner fields filled with team mailboxes or people who have left |
| Cloud and platform inventories | Owners and tags for service accounts, workload identities, applications and agents | Tags optional and inconsistent; many identities created by automation with no owner |
| Risk and governance records | Named risk owners, authorising officials, RACI charts for security processes | Documents, not data; updated annually at best |
The SCIM attributes matter because they let the same organisational data flow into SaaS applications in a standard shape. See the SCIM Provisioning Guide.
Where identity fits
The organisation model is where non-human identities either gain an owner or stay orphaned. A service account, a CI pipeline token or an AI agent has no line manager in HR, so the map must hold an explicit owns relation from a person (and a team, so ownership survives a leaver) to every such identity. That relation drives access reviews, rotation approvals and who is paged when the identity misbehaves. The practical steps are in How to assign owners to orphaned service accounts and the NHI Ownership Guide.
How to build it
- Agree the minimum schema. Start with organisational unit, position, person, manager, group, owner-of and the security roles you actually use (system owner, data owner, risk owner, incident approver). Resist modelling everything at once.
- Name the authoritative source per attribute. HR for hierarchy and employment status, the directory for groups, IGA for business roles and approvers, the platform inventory for non-human identities. Write this down; conflicts are resolved by the source, not by whoever edited last.
- Load and join on stable keys. Join people on an immutable identifier such as an employee number, not email or display name, which change on marriage, rebrand or merger.
- Add external personnel. Contractors, supplier staff and managed service accounts need a sponsor in the organisation and an end date. Without these they become the long tail of unowned access.
- Attach every non-human identity to a person and a team. Run an ownership campaign for unowned service accounts and workload identities, using creation logs and usage to find likely owners, and block creation of new ones without an owner field.
- Drive updates from lifecycle events. Feed joiner, mover and leaver events into the model so a manager change or a team move updates owner relations, approvers and group expectations the same day. The Joiner-Mover-Leaver Guide covers the event design.
- Publish it where responders work. Expose owner and manager lookups to the SIEM, the ticketing system and the on-call tool so an alert on an account or host shows the accountable person automatically.
- Test, then roll out. Pilot with one business unit, compare the model against what the unit's managers say is true, fix the source data rather than the model, then extend.
How it feeds other D3FEND techniques
| Downstream use | What the organisation model supplies |
|---|---|
| Access Modeling (D3-AM) and permission hardening such as D3-UAP User Account Permissions | The expected access for a role or team, so excess permissions stand out |
| D3-DAM Domain Account Monitoring and user behaviour analysis | Peer groups for baselines and the owner to contact when an account behaves oddly |
| Operational Dependency Mapping (D3-ODM) | Which teams and people an activity depends on, including single points of knowledge |
| Operational Risk Assessment (D3-ORA) | Named risk owners and the organisational scope of each risk |
| Incident response and eviction techniques | Who can approve disabling an account or isolating a host, and who must be informed |
| Segregation of duties checks | Role and reporting-line data needed to detect toxic combinations; see the Segregation of Duties Guide |
How to verify it is working
An organisation model is only useful if it is right at the moment someone queries it. Measure that directly.
- Owner coverage: percentage of human accounts with a valid active manager, and of non-human identities with an active owning person and team.
- Orphan rate after leavers: number of owner relations pointing at departed people seven days after their leave date.
- Source agreement: mismatches between HR department or manager and the directory attributes, tracked weekly.
- Response lookups: share of security alerts where the owner was resolved automatically, sampled monthly from closed incidents.
- Reorganisation lag: days between an announced reorganisation and the model reflecting it.
Targets are a local decision. As an example only (an NHI Mgmt Group suggestion, not a standard), a mature programme might aim for owner coverage above 95% for non-human identities and no stale owner relations older than seven days.
Common failure patterns
- Treating the HR chart as the whole map: HR has no service accounts, often no contractors and no security roles, so a map built only from HR misses the identities most likely to be abused.
- Owners that are mailboxes or teams only: a shared mailbox cannot approve access or answer at 3am. Keep a team for continuity and a named person for accountability.
- Joining on email or display name: renamed people split into two records and merged departments break joins. Use immutable identifiers.
- Annual refresh: a model rebuilt once a year for an audit is wrong for most of the year. Event-driven updates are the only reliable approach in organisations with frequent moves.
- Ignoring reorganisations and divestitures: when units are sold or merged, approvers and owners move in bulk. See Identity separation in divestitures.
- Over-modelling: projects that try to capture every committee and informal relationship stall. Model what an access decision or an incident needs.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RR-02 | Roles, responsibilities and authorities for cybersecurity risk management are established, communicated, understood and enforced |
| NIST CSF 2.0 | GV.OC-05 | Outcomes, capabilities and services the organisation depends on are understood |
| NIST SP 800-53 Rev 5 | PM-29, PS-9, PM-13 | Risk management programme leadership roles, position descriptions, security and privacy workforce |
| NIST SP 800-53 Rev 5 | AC-2, AC-5 | Account management (including account managers and authorised users) and separation of duties |
| NIST SP 800-53 Rev 5 | PM-7 | Enterprise architecture, where organisation models are usually maintained |
| ISO/IEC 27001:2022 Annex A | 5.2, 5.3, 5.4 | Information security roles and responsibilities, segregation of duties, management responsibilities |
| MITRE D3FEND | D3-OAM, D3-OM | Parent and technique |
For the wider activity model that D3-OM is part of, see the MITRE D3FEND Operational Activity Mapping Implementation Guide.
Practitioner checklist
- Write down the authoritative source for each organisational attribute.
- Join records on immutable identifiers, not email or names.
- Include contractors and supplier staff with a sponsor and an end date.
- Give every service account, workload identity and AI agent an owning person and team.
- Block creation of new non-human identities without an owner.
- Update the model from joiner, mover and leaver events, not annual exports.
- Expose owner and manager lookups in the SIEM and ticketing tools.
- Track owner coverage, stale owner relations and HR to directory mismatches.
- Record security roles (system owner, risk owner, incident approver) as data, not documents.
Standards and references
- MITRE D3FEND: Organization Mapping (D3-OM)
- OMG: Unified Architecture Framework (UAF)
- IETF: RFC 7643 System for Cross-domain Identity Management: Core Schema
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: SP 800-37 Rev. 2 Risk Management Framework
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: MITRE D3FEND Operational Activity Mapping Implementation Guide · NHI Ownership Guide · IT and Security RACI Template · Entitlement Catalogue Guide · MITRE D3FEND Guide