The practice model

Name the decision owner

Every security exception, risk acceptance and material architecture decision has one accountable owner.

Use named privileged access

Eliminate shared administrative identities. Record who elevated, what they accessed and when the privilege ended.

Record security decisions

Keep a decision record for significant changes, exceptions and risk acceptances.

Define ownership

Every critical security control has an accountable owner and an operational owner.

Make escalation explicit

Define who must be informed when a security decision exceeds the team's authority.

Time-bound exceptions

Every exception has a reason, risk owner, compensating control and expiry date.

Review consequential changes

Require independent review for high-impact firewall, identity, security-policy and production changes.

Separate approval from execution

Where risk warrants it, the person implementing a sensitive action should not be the sole person approving it.

Preserve audit trails

Ensure administrative actions cannot be altered or deleted by the same identity that performs them.

Formalise risk acceptance

Define who can accept which level of security risk and for how long.

Audit attribution

Periodically test whether consequential administrative actions can actually be attributed to an individual.

Measure stale exceptions

Track exceptions past their review or expiry date.

Review shared accounts

Search for shared, generic and service identities that create attribution gaps.

Test decision records

Sample architecture and security decisions and verify that the stated owner, evidence and approval exist.

Report accountability gaps

Include unattributed privileged activity and overdue ownership actions in security reporting.

Learn from accountability failures

Use incidents and near misses to identify where responsibility was unclear.

Reduce manual attribution

Automate identity correlation across PAM, IAM, SIEM and infrastructure platforms.

Reassess authority boundaries

Review whether decision rights still match the organisation's current architecture and operating model.

Challenge risk acceptance

Periodically review recurring accepted risks and determine whether the organisation has normalised them.

Make accountability part of architecture

Design new platforms so that identity, action and evidence remain linked by default.

Define escalation thresholds

Give analysts clear conditions under which suspicious activity must be escalated.

Run basic threat hunts

Regularly investigate behaviours that existing detections may miss.

Establish incident authority

Define who can isolate a device, disable an account or block traffic during an incident.

Create challenge points

Require security review for architectures and changes that introduce material exposure.

Document uncertainty

Allow incident teams to record hypotheses as hypotheses instead of forcing premature conclusions.

Exercise incident response

Run tabletop and technical exercises where information is deliberately incomplete.

Maintain hunting hypotheses

Turn intelligence, incidents and unusual telemetry into repeatable hunting questions.

Define containment playbooks

Pre-authorise common containment actions so teams do not need to negotiate authority during an incident.

Establish independent escalation

Allow analysts to escalate significant concerns without requiring approval from the team being investigated.

Protect useful challenge

Create a process for challenging high-risk decisions without turning disagreement into personal conflict.

Measure detection-to-investigation time

Track how quickly suspicious signals receive meaningful investigation.

Measure investigation outcomes

Record how many hunts produce new detections, vulnerabilities, compromised assets or useful negative findings.

Test blind spots

Periodically simulate activity that existing detection rules should not identify.

Review closed alerts

Sample alerts closed as benign and test whether the reasoning was sound.

Track delayed escalation

Identify incidents where evidence existed but action was delayed.

Turn hunts into detections

Convert repeatable hunting discoveries into automated or semi-automated detection.

Feed incidents into architecture

Use recurring investigation findings to change identity, network, endpoint and application design.

Rehearse decision-making under pressure

Run exercises where business impact and incomplete evidence compete for attention.

Challenge detection assumptions

Regularly ask what the SOC cannot currently see and what an attacker could do without generating an alert.

Reward justified intervention

Recognise analysts and engineers who escalate credible concerns early, including cases that ultimately prove benign.

Identify the user

For every important control, identify who operates it and what legitimate task they need to complete.

Document the secure path

Make the approved way to perform common tasks clear and accessible.

Provide a security support path

Give users a practical way to resolve security-related blockers.

Make reporting easy

Provide simple mechanisms for reporting phishing, lost devices, suspicious activity and accidental exposure.

Explain the reason

Tell users what a control protects and what behaviour is expected.

Automate the safe path

Automate access requests, credential rotation, approved software deployment and similar repetitive tasks.

Design with users

Test security workflows with administrators, developers and business users before deployment.

Build approved alternatives

When blocking a risky activity, provide a supported way to accomplish the legitimate business requirement.

Measure friction

Track access-request time, authentication failures, exception requests and security-related support demand.

Review workarounds

Treat repeated bypasses as signals that the control or process needs examination.

Measure abandonment

Identify security workflows that users start but do not complete.

Track exception demand

Look for teams repeatedly requesting the same exception.

Measure secure-path adoption

Determine whether users actually use the approved workflow.

Test usability after deployment

Reassess controls after major changes in technology or business processes.

Correlate friction with incidents

Look for relationships between difficult controls and unsafe workarounds.

Remove recurring friction

Prioritise engineering work that eliminates repeated security workarounds.

Use risk-based controls

Apply stronger controls where risk requires them and reduce unnecessary friction elsewhere.

Continuously redesign workflows

Treat security user experience as an operational product that needs maintenance.

Automate exception alternatives

Where the same exception appears repeatedly, determine whether it should become a supported pattern.

Measure security by behaviour

Include user adoption and workaround rates when evaluating whether a control is successful.

Define access requirements

Document what access each role actually requires.

Identify trust boundaries

Document important identity, network, application and data boundaries.

Establish access owners

Every sensitive resource has an owner responsible for access decisions.

Classify sensitive information

Define which information requires additional access restrictions.

Establish temporary-access rules

Define how project, vendor, emergency and privileged access is granted and removed.

Review privileged access

Regularly remove access that is no longer required.

Expire temporary access

Make temporary access expire automatically wherever possible.

Enforce least privilege

Grant access according to role, task and necessity.

Separate duties

Prevent one person from controlling sensitive approval and execution paths where risk warrants it.

Enforce segmentation

Restrict communication between systems according to documented requirements.

Test access paths

Verify that users cannot reach resources outside their intended scope.

Test segmentation

Verify that prohibited network paths are actually blocked.

Measure excessive privilege

Identify users, service accounts and applications with broader access than required.

Review stale vendor access

Track external identities that remain active beyond their business need.

Audit access exceptions

Measure how many access decisions bypass the normal process.

Move toward continuous authorisation

Reassess access based on identity, device, context and resource sensitivity.

Reduce standing privilege

Replace permanent access with just-in-time or task-based access where appropriate.

Revalidate trust boundaries

Review segmentation and access models when applications, organisations or infrastructure change.

Automate entitlement removal

Connect joiner-mover-leaver events to access removal.

Treat access as a lifecycle

Design access from creation through review to removal rather than as a one-time approval.

Define authoritative sources

Identify which system is authoritative for assets, identities, vulnerabilities, configurations and other security data.

Define data ownership

Assign owners to important security datasets.

Record freshness

Make the age of security data visible.

Distinguish unknown from compliant

Do not treat missing telemetry as a passing result.

Document measurement limits

State what each security metric includes and excludes.

Reconcile inventories

Compare CMDB, cloud inventories, endpoint platforms, vulnerability scanners and network discovery.

Monitor security telemetry

Detect when log sources, agents, scanners or integrations stop reporting.

Validate critical metrics

Check the underlying data behind important dashboards.

Protect security records

Restrict modification and deletion of logs, evidence and audit records.

Establish data-quality workflows

Assign discrepancies to owners and track them to resolution.

Measure inventory coverage

Track the percentage of assets represented across required security systems.

Measure telemetry coverage

Track which critical systems are actually producing the expected logs.

Measure data freshness

Identify security data that has become too old to support decisions.

Sample compliance claims

Test whether reported compliance matches actual configuration.

Track reconciliation gaps

Measure recurring differences between authoritative and operational datasets.

Automate reconciliation

Continuously compare inventories and security platforms.

Detect silent failure

Alert when a security control stops producing expected evidence.

Propagate data quality

Prevent incomplete or stale source data from being presented as authoritative downstream.

Link metrics to evidence

Allow important security claims to be traced back to the underlying records.

Make uncertainty operational

Use confidence and coverage information when prioritising security decisions.

Define internal standards

Set security expectations that are clear and operational.

Assign control owners

Give every important control a responsible owner.

Define evidence

Specify what demonstrates that a control operates.

Define control frequency

State how often important controls must operate or be tested.

Record known failures

Create a visible process for reporting controls that do not work.

Run continuous assurance

Test important controls throughout the year.

Track control degradation

Monitor controls as systems, ownership and integrations change.

Fix internally discovered issues

Do not wait for an audit or regulator to identify known weaknesses.

Review standards

Update standards when architecture, threats or business processes change.

Separate compliance from security

Track regulatory compliance and internal security objectives separately.

Measure control effectiveness

Measure whether controls produce the intended result, not only whether they exist.

Track overdue assurance

Monitor controls that have not been tested on schedule.

Measure recurring findings

Identify weaknesses that repeatedly appear in audits and assessments.

Report control failures

Include failed controls in management reporting.

Compare internal and external findings

Identify problems that internal assurance should have found earlier.

Raise the internal standard

Increase expectations when the organisation can support them and the risk warrants it.

Automate control assurance

Use technical evidence where possible instead of manual evidence collection.

Remove recurring control failures

Treat repeated findings as process or architecture problems.

Challenge accepted weaknesses

Review whether long-standing accepted risks are still justified.

Test before the audit

Use internal assurance to establish the actual state before external scrutiny arrives.

Assign system ownership

Every important system has a named business or technology owner.

Define security responsibilities

Make security duties part of relevant roles.

Teach intervention

Tell people what to do when they see suspicious activity or unsafe behaviour.

Provide reporting mechanisms

Make reporting accessible without requiring specialist knowledge.

Define stewardship expectations

Make clear what responsibility comes with privileged or sensitive access.

Include security in role definitions

Make security responsibilities explicit for administrators, developers, engineers and system owners.

Review responsibility with access

When sensitive access is renewed, confirm the user's continuing responsibility.

Build security into operational processes

Include security checks in deployment, onboarding, change and decommissioning workflows.

Establish vendor responsibility

Define security responsibilities for third parties with access to company systems.

Support responsible reporting

Ensure employees can report mistakes and suspicious activity without first resolving the issue themselves.

Measure ownership coverage

Track systems and controls without an accountable owner.

Measure reporting behaviour

Track useful reports of phishing, suspicious activity and control failures.

Measure unresolved ownership

Identify security issues waiting because responsibility is unclear.

Review privileged stewardship

Sample privileged users and verify that access remains justified and understood.

Measure security participation

Track participation in exercises, training and operational security activities.

Push responsibility toward the edge

Move appropriate security decisions closer to the teams operating the systems.

Integrate security into engineering

Make security part of normal engineering workflows rather than a separate approval stage.

Use incidents to clarify ownership

Where an incident exposes responsibility gaps, change the operating model.

Build security into performance expectations

Where appropriate, include security responsibilities in team and role objectives.

Treat privilege as stewardship

Review whether privileged access is still supported by the responsibility that justified it.

Define change classes

Distinguish normal, standard, emergency and high-risk changes.

Establish emergency procedures

Define what can be changed during an incident and who can authorise it.

Record privileged actions

Capture administrative activity in critical environments.

Define temporary exceptions

Give temporary changes and exclusions an explicit end condition.

Establish rollback expectations

Define how high-impact changes can be reversed.

Use just-in-time privilege

Grant elevated access for the task and remove it when the task ends.

Require peer review

Use independent review for high-impact changes where risk warrants it.

Automate expiry

Automatically remove temporary firewall rules, exclusions, privileges and exceptions where possible.

Protect emergency access

Log and restrict emergency administrative capabilities.

Use infrastructure as code

Prefer controlled, repeatable changes over undocumented manual modification.

Measure emergency changes

Track how often emergency procedures are used.

Measure rollback

Track changes that require rollback and identify recurring causes.

Measure standing privilege

Identify elevated access that remains active beyond operational need.

Audit temporary controls

Find expired exceptions, exclusions and temporary rules that remain active.

Review manual changes

Identify production changes performed outside approved mechanisms.

Reduce emergency demand

Use recurring emergency changes to identify weaknesses in architecture or process.

Automate controlled remediation

Where the action is predictable, make the safe response repeatable.

Improve rollback capability

Invest in reversible deployments and configuration recovery where failure has material impact.

Design for pressure

Test whether security processes still work during outages, incidents and high business pressure.

Learn from exceptions

Treat repeated emergency behaviour as evidence that the normal operating model needs to change.