ACTIVITIES

A.  Estimate overall process risk profile

Interview business owners, process owners and stakeholders and create a list of worst-case scenarios across the organization's human procedures. Based on the way your organization operates, the list can vary widely, but common issues include an attacker talking the service desk into resetting an executive's credentials, a departing employee retaining access nobody removed, a fraudulent payment approved because the approval step was a formality, and a support process — human or AI-assisted — disclosing information to someone who had not been properly identified.

After broadly capturing worst-case scenario ideas, collate and select the most important based on collected information and knowledge about the core business. Any number can be selected, but aim for at least 3 and no more than 7 to make efficient use of time and keep the exercise focused.

Elaborate a description of each of the selected items and document details of contributing worst-case scenarios, potential contributing factors, and potential mitigating factors for the organization.

The final process risk profile should be reviewed with business owners and other stakeholders for understanding.

B.  Build and maintain assurance program roadmap

Understanding the main business risks to the organization, evaluate the current performance of the organization against each of the twelve Practices. Assign a score for each Practice from 1, 2, or 3 based on the corresponding Objective if the organization passes all the cumulative success metrics. If no success metrics are being met, assign a score of 0 to the Practice.

Once a good understanding of current status is obtained, the next goal is to identify the Practices that will be improved in the next iteration. Select them based on the process risk profile, other business drivers, compliance requirements, budget tolerance, etc. Once Practices are selected, the goals of the iteration are to achieve the next Objective under each.

Iterations of improvement should be approximately 3-6 months, but a strategy session should take place at least every 3 months to review progress on activities, performance against success metrics and other business drivers that may require program changes.

ACTIVITIES

A.  Conduct periodic industry-wide cost comparisons

Research and gather information about process security costs from intra-industry communication forums, business analyst and consulting firms, or other external sources.

First, use collected information to identify the average effort being applied by similar organizations. This can be done top-down from estimates of total effort devoted to identity verification, approvals and awareness, or bottom-up by identifying the controls and activities considered normal for organizations of your kind.

The next goal is to determine whether there are savings available on the tooling your organization uses for verification, awareness training, phishing simulation and access lifecycle, which is frequently bought piecemeal and overlaps. Account for hidden costs such as retraining staff when switching approaches.

These exercises should be conducted at least annually prior to the subsequent strategy session, and comparison information presented to stakeholders in order to better align the program with the business.

B.  Collect metrics for historic process incidents

Collect information on the cost of past process failures. Fraud losses from abused approvals, the cost of responding to a help-desk social-engineering breach, the exposure from access left in place after departures, and the effort spent cleaning up after a procedure was bypassed are the usual components.

Using the procedure classifications and the respective roadmaps for each, a baseline assurance cost per tier can be initially estimated from the costs associated with the corresponding classification.

Combine the per-tier cost information with the general cost model, then evaluate for outliers, i.e. sums disproportionate to the classification. These indicate either an error in classification or the necessity to tune the program to address root causes more effectively.

Tracking should be done quarterly at the strategy session, and the information reviewed by stakeholders at least annually.

ACTIVITIES

A.  Identify and monitor external compliance drivers

Gather the regulations, contractual obligations and standards that place requirements on how the organization's procedures are run. Financial controls regimes, identity-proofing standards, data-protection duties around access and authorization, and sector rules all impose requirements that land on human process.

For each driver, extract the obligations that land on a procedure — separation of duties, dual authorization above a threshold, verified identity before an account action, timely removal of access on departure, and retained evidence that each was done.

Assign an owner for each driver and establish a review to catch changes, since identity-proofing and fraud-control expectations are tightening in response to the rise of social-engineering attacks on support processes.

B.  Build and maintain procedure guidelines

Consolidate the obligations into guidelines expressed in terms the teams who run procedures can act upon. Regulators speak in principles; a service-desk agent or an approver needs to know exactly what to check and when to refuse.

Cover the procedures where the stakes are highest: how to verify someone's identity before acting on their account, how sensitive actions are authorized and by whom, how access is granted and removed as people join and leave, and how a suspected manipulation is escalated. Where AI assistants perform any of these steps, the guidelines must cover them too, since an assistant that can reset a credential inherits the same obligations as a human agent.

Publish the guidelines where the relevant teams work and review them at least annually.

ACTIVITIES

A.  Conduct periodic compliance audits of procedures

Move from confirming a procedure's design to confirming how it is actually run. Procedures drift: a verification step is skipped when the queue is long, an approval becomes a rubber stamp, an emergency exception becomes the everyday route.

Audit against the internal standards and the inventory, and — crucially — observe the procedure being performed rather than only reading its documentation, since the gap between the written process and the lived one is exactly where the risk lives. Look for the sensitive procedures that grew up informally and were never brought under control.

Each sensitive procedure should undergo audit at least biannually, with the most critical reviewed more often.

B.  Collect and control compliance evidence

Establish a repository of evidence sufficient to satisfy an auditor without a scramble: the procedure inventory, records of verifications and approvals for sensitive actions, access-grant and removal records tied to joiner and leaver events, separation-of-duties attestations, and exception records.

Automate collection wherever possible, particularly the approval and access evidence generated continuously by everyday operation. Evidence reconstructed by hand at audit time is expensive and, for something as time-sensitive as 'was this access removed when this person left', frequently cannot be reconstructed at all.

Report adherence to stakeholders at least quarterly, trending over time.

ACTIVITIES

A.  Conduct process and social-engineering awareness training

Offer the staff who perform sensitive procedures — the service desk above all — access to training covering how their procedures are attacked, reflecting the manipulation techniques actually used against organizations like yours.

Cover the tactics that work: the attacker who builds rapport over several calls, who manufactures urgency and authority, who has already gathered enough personal detail to pass a knowledge-based check, and who exploits the agent's genuine wish to be helpful. Teach that being socially engineered is not a personal failing but the predictable result of a weak procedure, so that agents feel safe slowing down and refusing.

Extend the same awareness to the general workforce, who are the targets attackers phish and vish to gather the details that later defeat verification.

Aim to reach everyone who performs sensitive procedures within a year, and refresh at least every two years as tactics evolve.

B.  Build and maintain procedure guidance and scripts

Assemble reference guidance — including scripts and decision aids used in the moment — covering the specific procedures your organization expects, rather than restating general advice available elsewhere.

Practical material includes how to verify identity for each kind of account action, what to do when a caller cannot be verified, how to recognize and respond to pressure, when and how to escalate, and — importantly — how to verify someone without asking questions that themselves teach an attacker what the organization checks, or that train legitimate users to hand over secrets on request.

Keep the guidance lightweight and current, and make it usable live rather than as a document to study beforehand.

ACTIVITIES

A.  Establish role-based examination and certification

Introduce assessment so competency is demonstrated rather than assumed, particularly for the roles that verify identity, authorize sensitive actions, or hold the authority to override a control.

Tie certification to authority where the risk warrants it. The ability to reset credentials, to approve high-value transactions, or to grant privileged access is a reasonable thing to gate on demonstrated competence — including in resisting realistic social-engineering pressure — reviewed periodically.

The most informative assessment here is behavioral rather than a test of recall: put agents through realistic simulated manipulation and see whether the procedure holds, which is measured in Security Testing and fed back into who is certified.

B.  Establish centralized guidance control

Bring the guidance and scripts under central control with clear ownership, review cycles and version history, so the organization can state with confidence what its current expectations are.

Distribute from a single authoritative source and retire superseded material actively, which matters for procedures since an out-of-date verification script can actively teach an agent to do the wrong thing.

Measure whether guidance is reaching people and being used, and feed that back into the roadmap.

ACTIVITIES

A.  Build and maintain procedure abuse models

For each sensitive procedure, build a lightweight model of how it could be manipulated. A workshop and a page of notes per procedure is enough to start.

Work through the ways a procedure turns into an attack. An attacker impersonates an employee to the service desk and obtains a reset. A fraudulent instruction arrives bearing an executive's apparent authority. An approval is sought at a moment engineered to seem urgent. A joiner is over-provisioned, or a leaver never deprovisioned. A support assistant is talked, or prompt-injected, into an action it should have refused.

Record for each threat what currently stands in the way, and note honestly where the only thing standing in the way is a person's judgement under pressure, since those are the procedures most in need of a stronger step.

Review the models with the teams who run each procedure and refresh at least annually.

B.  Develop attacker profile for process abuse

Characterize who would manipulate your procedures and how. The opportunist testing the service desk, the organized group running a rehearsed impersonation campaign, the insider abusing legitimate access, and the fraudster redirecting a payment all call for different defenses.

Ground the profile in how the organization's procedures actually work and who can invoke them. An organization whose service desk can reset any credential on a phone call carries different risk from one where high-consequence resets require out-of-band confirmation, whatever the external threat.

Document the profiles alongside the abuse models so the two are read together.

ACTIVITIES

A.  Explicitly evaluate risk from delegated and AI-assisted procedures

Extend threat assessment to the procedures the organization has handed to others or to automation: steps performed by outsourced service desks and business-process providers, and steps performed by AI assistants standing in front of support and account-recovery flows.

For delegated procedures, establish what the provider's agents can actually do and whether their verification is as strong as your own, since an outsourced desk with weaker checks becomes the soft way in. For AI-assisted steps, treat the assistant as a manipulable actor: assess what it can be induced to do through crafted instructions or injected content, and whether a high-consequence action it takes has an independent check behind it.

Reassess when the arrangement changes — a provider altering its process, or an assistant being given a new capability, can open a path that did not exist before.

B.  Elaborate abuse models with controls

Complete the mapping from each identified threat to the specific controls that mitigate it — procedural, technical and supervisory — and record the residual risk that remains after those controls apply.

This mapping is what lets an organization answer the question its leadership actually asks after a social-engineering breach — not 'was the agent trained' but 'what, other than that agent's judgement, stood between the attacker and the objective'. It also exposes controls that mitigate nothing in the current model and are candidates for retirement.

Maintain the mapping as procedures change, and review residual risk with business owners at least annually, giving particular scrutiny to any high-consequence procedure whose only real control is a human or an assistant being careful.

ACTIVITIES

A.  Derive requirements from procedure sensitivity

For each sensitive procedure, work from what it can do to the assurance it must provide before it acts. Start from the consequence of getting it wrong rather than a generic checklist.

A short set per procedure is enough at this level. Typical entries include the standard of identity verification required before the action, whether a second person must independently authorize it, what evidence is recorded, and what the agent should do when verification fails — which is refuse, not proceed apologetically.

Specify verification that resists research and phishing: prefer confirmation through a channel the organization already trusts over questions about facts an attacker can gather, and never require the person to reveal a secret the attacker could then harvest by impersonating the organization.

Have the requirements reviewed by the team that will run the procedure, since a verification standard nobody can meet under real pressure is not yet a requirement.

B.  Evaluate compliance and abuse models for requirements

Draw on the procedure guidelines and abuse models to catch requirements that sensitivity alone would not surface.

Compliance drivers frequently mandate specific requirements — separation of duties, dual authorization, identity-proofing standards — and the abuse models will suggest others, particularly the out-of-band confirmation that defeats impersonation and the independent check behind any action an assistant can take.

Consolidate into a single requirement set per procedure so the people implementing it have one reference to work from.

ACTIVITIES

A.  Build requirements into provider and assistant arrangements

Carry the organization's requirements into the procedures run on its behalf — by outsourced service desks and business-process providers — and into the configuration of the AI assistants it deploys in front of sensitive flows.

For providers, specify the verification and authorization standard their agents must meet, the evidence they must produce, and the right to test them, since a provider's weaker procedure becomes your breach. For assistants, specify the actions they may take unaided, the human-in-the-loop checks required for the rest, and the resistance to manipulation they must demonstrate before deployment.

For critical procedures, negotiate these deliberately rather than accepting a provider's or a product's defaults, which are set for convenience rather than for your risk.

B.  Expand audit program for procedure requirements

Extend routine audit to cover whether procedures as run — by staff, providers and assistants — actually meet the requirements specified for them, closing the loop between what was specified and what happens in practice.

Audit the provider and assistant arrangements too. A contractual verification standard is only useful if the provider's agents actually apply it, and an assistant's guardrail is only useful if it holds against a determined attempt, which is why this Practice connects directly to the deliberate testing in Security Testing.

Report findings into the strategy session so requirement failures inform the roadmap rather than being handled solely as individual exceptions.

ACTIVITIES

A.  Maintain a set of approved verification and approval methods

Publish the verification and authorization methods the organization endorses, and keep it curated. A short set of vetted, well-understood methods concentrates effort and steers designers away from inventing weak ones.

Base inclusion on resistance to the attacks that matter — prefer out-of-band and phishing-resistant confirmation over knowledge-based questions, and dual authorization over single-person sign-off for high-consequence actions. Record the methods that are not to be used, such as verification by facts an attacker can research, as clearly as the approved ones.

Give the set an owner and a review cadence, since the manipulation techniques it defends against evolve, and a method that was adequate two years ago may now be routinely defeated.

B.  Identify and promote secure procedure principles

Establish the handful of principles every procedure design should honor, and make them explicit so decisions can be checked against something.

The durable ones are: verify to a standard matched to the stakes; require a second person for actions too dangerous for one; separate duties so no individual can complete a sensitive transaction alone; confirm high-consequence requests out-of-band; make urgency a reason for more scrutiny rather than less; and keep a human in the loop behind any consequential action an assistant performs.

Circulate the principles to the teams who design procedures and use them as review criteria.

ACTIVITIES

A.  Build reference procedures

Produce complete reference procedures for the recurring processes the organization runs — not documents describing a process, but ready-to-adopt workflows that build in the verification, approvals, separation of duties and escalation by construction.

The goal is that the easy path is the safe path: a team standing up a new support or approval process from the reference gets tier-appropriate verification, the right approvals, and an escalation route by default, and would have to work to make it unsafe. This removes the largest single source of weakness, which is procedures improvised under time pressure.

Maintain the reference procedures under change control with review and versioning, and make them genuinely easier to adopt than improvising, since adoption follows convenience more reliably than policy.

B.  Validate usage of reference procedures

Verify that procedures in operation were in fact built from the reference workflows and continue to match them, rather than assuming that publishing a reference ensures its use.

Procedures that grew up outside the standard process — the informal favor, the urgent workaround, the process inherited from an acquisition — are the ones that will not match, and they are where the dangerous shortcuts live.

Report the proportion of sensitive procedures built from reference workflows as a programme metric, and route exceptions through the documented process rather than letting them accumulate silently.

ACTIVITIES

A.  Identify the decision and trust points of a procedure

For each proposed procedure, document where a person makes a decision, where identity or authority is trusted, and what the procedure can do once it proceeds. This is the process equivalent of an attack surface and it need not be elaborate.

Record who can invoke the procedure, what identity check gates it, who authorizes the sensitive action, what the procedure can do in the wrong hands, and where it trusts that a previous step did its job. The trust points — where one step assumes another already verified — are where the surface is largest and least visible.

The exercise is most valuable for high-consequence procedures and for anything that verifies identity, grants access or moves money, since that is where a weak design does lasting harm.

B.  Check the design against known abuse

Review each proposed procedure against the organization's abuse models and secure procedure principles, asking of each identified manipulation what this design does about it.

Concentrate on the decisions that are hard to change later: whether the verification resists research and phishing, whether a single person can complete a dangerous action, whether urgency waives the checks, whether an assistant can take a consequential action unaided, and whether a failed verification leads to a clean refusal or to an agent improvising.

Record the review outcome with the design. Even an informal note stating who reviewed it and what was raised gives the next reviewer a starting point.

ACTIVITIES

A.  Develop detailed manipulation and failure review

Deepen review to walk each proposed procedure through the ways it could be manipulated or could fail, rather than accepting its happy path.

Work the failure through. If an attacker impersonated a user to this procedure, what would stop them, and would the agent recognize it? If the approver were deceived, what independent check would catch it? If urgency were manufactured, does the emergency path still verify? If the assistant were prompt-injected, what would prevent the consequential action? These questions are answerable at design time and expensive to answer after an incident.

Give particular attention to the seams between this procedure and the ones it hands off to, since that is where designs most often assume a check that was never actually performed.

B.  Require reviews and audit design compliance

Make review mandatory for high-consequence procedures, and verify through routine audit that the requirement is met rather than assuming it.

Audit both that reviews happened and that their conditions were implemented. A review that concluded 'approved provided high-value resets require out-of-band confirmation' is worth nothing if the procedure went live without it.

Feed audit findings into the strategy session so systematic review failures are addressed as programme problems rather than individually.

ACTIVITIES

A.  Create review checklists from the intended procedure

Build a checklist per sensitive procedure from its design and requirements, expressed as things that can actually be observed when the procedure is performed.

Keep it to what carries real weight: was identity verified to the required standard, was the required approver independent and did they actually verify, was separation of duties maintained, was the emergency path used only when justified, and — where an assistant is involved — did a human review the consequential action.

Have the checklist reviewed by the teams who perform each procedure, since they will know which steps are commonly skipped and why, which is itself valuable intelligence about where the design is unworkable.

B.  Observe and review high-consequence procedures

Watch high-consequence procedures being performed and check them against the checklist, rather than relying on the documentation or on the performer's account of what they do.

Direct observation matters because people describe the intended procedure and perform the practical one, usually without any intent to cut corners — the skipped step feels safe because it has never yet caused harm. Reviewing recorded interactions, sampling completed approvals for genuine independence, and sitting with the service desk reveal the lived procedure that no document describes.

Record findings and route them for remediation with an owner and a date. A shortcut found is either designed out, made unnecessary, or the design is fixed so the safe path is workable — never left because the shortcut is convenient.

ACTIVITIES

A.  Customize review for organization-specific concerns

Extend systematic review beyond generic checks to the process concerns specific to your organization that no standard checklist would capture.

These are usually the interesting ones: the specific shortcut a previous incident revealed, the combination of two roles that must never rest with one person, the procedure a particular fraud exploited, or the emergency exception that must trigger review every time it is used.

Maintain these custom checks with the same discipline as the standard ones, since a check written after an incident years ago may now be enforcing something obsolete.

B.  Make deviation structurally difficult

Move enforcement from detecting deviation to preventing it, by building the procedure so that the unsafe shortcut is genuinely hard to take rather than merely against the rules.

The most effective moves are structural: an approval workflow that technically cannot be completed by one person, a sensitive action that will not proceed without the verification recorded, an emergency path that always raises an alert and a review. This turns 'the agent should have verified' into 'the action could not complete without verification', which is the difference between a control that depends on discipline and one that does not.

Where a shortcut cannot be prevented outright — because a genuine emergency must be possible — ensure it is expensive to invoke and always reviewed, so that the easy path stays the safe one. Report into the strategy session so systematic weaknesses drive the roadmap.

ACTIVITIES

A.  Derive test cases from known requirements

Turn the requirements for each sensitive procedure into tests that can actually be run, so a requirement can be shown to hold rather than asserted.

Start with the controls the organization is most relying upon. If the procedure rests on identity verification, the test is to present a plausible but unverifiable request and confirm it is refused. If it rests on dual authorization, the test is to attempt a sensitive action with a single approver. If it rests on an assistant's guardrail, the test is to attempt to talk the assistant past it.

Document the expected result alongside each test so a change after a procedure update or a staff change is noticed.

B.  Conduct controlled social-engineering tests

Have a sanctioned tester attempt to manipulate the organization's procedures the way a real attacker would, working from a realistic starting position rather than with inside help.

Useful attempts at this level include calling the service desk to obtain a reset without proper verification, seeking an approval through a normal channel with a manufactured justification, and attempting to induce a front-line assistant into a prohibited action. The question in each case is whether the procedure held and whether the attempt was recognized and reported.

Conduct the test against the procedure as normally performed, and run it with care: authorized in advance, aimed at the procedure rather than the individual, and concluded with feedback that strengthens the process. Record findings against the reference procedure so remediation lands in the design rather than on one person.

ACTIVITIES

A.  Employ organization-specific test cases

Generate test cases from your own manipulation paths and abuse models rather than a generic catalogue, so testing addresses the paths that matter for your organization.

Where a manipulation path shows a chain running through a trust seam, build a test that attempts the chain and establishes where it breaks. This produces findings expressed in terms of real business impact — an attacker could have obtained privileged access this way — which is what makes them actionable outside the security team.

Include the response process in scope. Testing whether a manipulation is detected, escalated and contained within the target time measures the whole system rather than any single agent's alertness.

B.  Establish a reliance standard for procedures

Define the testing a procedure must pass before it is relied upon for a high-consequence purpose, and hold the line on it.

Require the standard to be met through the reference procedure rather than by one-off effort, so that passing is inherited by everything built from the same workflow. This is the difference between assurance that scales and assurance that becomes a bottleneck.

Require audit evidence that the standard was met, and route exceptions through the documented process with a named approver.

ACTIVITIES

A.  Identify a blame-free reporting route and point of contact

Establish and publish an obvious, fast route for reporting a suspected process failure or manipulation, and make clear that reporting is welcomed rather than penalized.

The reports that matter most come from the person who realizes, after the fact, that they may have been tricked — the agent who reset the wrong person's password, the approver who signed off on something that now looks wrong, the employee who gave information to a convincing caller. If the response to these is punishment, they will not come, and the organization will learn of the breach from the attacker's actions instead.

Publish the route where people will find it under stress, make it reach a human quickly, and state plainly that raising a possible mistake early is exactly the right thing to do.

B.  Create informal process response capability

Assemble the people who can act when a process abuse is reported, with the authority to contain it quickly.

The capabilities that matter most are the ability to reverse or freeze what a manipulated procedure did — lock the account that was just reset, halt the payment that was just approved, revoke the access that was just granted — and to determine whether the incident is isolated or one move in a larger campaign. Many organizations discover during their first real case that the person taking the report cannot do any of this and must find someone who can, while the attacker acts.

Write down who holds these permissions and how they are reached, including out of hours, since social-engineering campaigns are deliberately timed for when the organization is least able to respond.

ACTIVITIES

A.  Conduct root-cause analysis of process incidents

Investigate what allowed each significant process abuse to succeed and what allowed it to matter, rather than closing on the immediate remediation.

The causes worth finding are structural, and the honest finding usually points away from the individual: the verification was too weak to stop a prepared attacker, the approval could be completed by one person, the emergency path waived the checks, the assistant could be talked past its guardrail, or the reporting was slow because people feared blame. Each is a programme finding — pointing at architecture, requirements or culture — rather than a failing of the person who was fooled.

Route causes to the Practice that owns them and track them to closure. Resisting the urge to blame the person is not only fairer but more effective, since a blamed workforce stops reporting and the next attack is discovered later.

B.  Collect and report process incident metrics

Instrument the process so its performance can be measured and trended, and report results into the strategy session.

The measurements that drive behavior are time from abuse to report, report to containment, the proportion of incidents involving procedures whose only control was human judgement, and — tellingly — how the report arrived, since a healthy programme sees most incidents surfaced by the people involved rather than discovered from the damage. Reporting speed and reporting rate are the leading indicators of a strong process culture.

Trend over time rather than reporting snapshots, and use the data to argue for the roadmap rather than to allocate blame.

ACTIVITIES

A.  Establish an inventory of access-granting procedures

Establish and maintain a picture of the procedures through which people gain, keep and lose access and authority — onboarding, role changes, privileged grants, resets, offboarding — and what each can confer.

Inventory is foundational because every control is scoped by it. An organization cannot strengthen a verification it has not identified or remove access it does not know a procedure granted, and the procedures missing from the picture are disproportionately the informal ones that grew up outside design.

Reconcile sources rather than trusting one. HR events, the identity system's grant history, the service desk's actions and what managers report will each know about access changes the others do not, and the differences are the finding.

Record an owner for every access-granting procedure, since an ownerless procedure is neither strengthened nor retired.

B.  Apply baseline verification and access constraints

Establish baseline controls: verify identity to a standard matched to the action, and grant access matched to role.

Replace the weakest verification on the highest-consequence procedures first — move a sensitive reset off knowledge-based questions and onto an out-of-band or phishing-resistant confirmation. Grant new joiners the access their role requires and no more, and remove access promptly when people move or leave, which reconciliation reliably shows to be a longer overdue list than expected.

Handle the highest-consequence procedures first and measure coverage, since the meaningful number is how much of the sensitive activity is actually protected by strong verification and least-privilege access in practice, which is usually less than policy assumes.

ACTIVITIES

A.  Enforce least standing privilege and just-in-time access

Extend control so that dangerous power is not held continuously but granted only when needed and for as long as needed, since standing privilege is the prize a manipulated procedure hands an attacker.

Move high-consequence access from standing to just-in-time: granted on an approved, time-bound request and automatically removed afterward, so that even a successful social-engineering attack against the granting procedure yields access that expires rather than persists. Remove standing administrative rights in favor of elevation that is requested, approved and recorded. This dramatically shrinks what any single manipulated procedure can achieve.

Verify the enforcement holds where access is actually obtained, including the paths that bypass the main flow — the break-glass account, the emergency grant, the third-party integration.

B.  Reduce standing power and expand the hardening audit

Attack the root cause by leaving less standing power to steal, and bring the controls under routine audit so their continued effectiveness is verified rather than assumed.

Drive down standing privilege and dormant access: reclaim access accumulated across role changes, remove entitlements nobody uses, retire shared and generic accounts that defeat accountability, and shrink the population that can perform the most dangerous actions. Every standing privilege not held is one a manipulated procedure cannot confer.

Audit should confirm both that controls are present and that they are effective — a dual-authorization rule that one person can satisfy by holding both roles, or a leaver process that removes the obvious accounts but leaves the standing ones, is present but protecting little. Report into the strategy session so systematic weaknesses drive the roadmap.

ACTIVITIES

A.  Capture records of sensitive procedure performance

Identify the information required to establish who performed which sensitive actions and how, and ensure it is collected and retained centrally.

The core set is records of identity verifications and their outcomes, approvals and who gave them, access grants and removals tied to their triggering events, use of emergency and override paths, and — for assistant-performed steps — what the assistant did and whether a human reviewed it. Resets, privileged grants and high-value approvals deserve emphasis, since these are the actions social engineering most seeks to induce.

Collect to a destination the performer cannot alter, so that someone who abuses a procedure cannot erase the record of it.

Review the collected set with the people who respond to process incidents, since they will know which record they most often wish they had.

B.  Document procedures for typical process alerts

For the alerts process monitoring routinely produces, document what they mean and what the recipient should do.

Cover the common ones: a sensitive action performed without the required verification on record, an approval given by someone who should not have, a burst of resets or grants, use of an emergency path, access granted that role does not justify, and an assistant taking a consequential action unreviewed. For each, record the likely benign explanation as well as the malicious one, since most have both — the burst of resets is sometimes a genuine outage.

Keep the procedures where responders work, and review them when volumes change materially.

ACTIVITIES

A.  Expand audit program for process monitoring

Bring the monitoring itself under audit, verifying that the record the organization believes it has of sensitive actions is actually being produced and watched.

Audit for gaps rather than volume. The questions that matter are which sensitive procedures produce no reviewable record, which anomaly types have never fired when they plausibly should have, which alerts were raised and never actioned, and which actions can be performed through a path that bypasses monitoring entirely. A procedure that produces no record generates no alerts, which is easily mistaken for an absence of abuse.

Verify retention meets both compliance obligations and realistic investigation needs, since social-engineering breaches are frequently understood only weeks after the manipulation that began them.

B.  Validate offboarding and access removal across the person lifecycle

Establish and verify that people are offboarded cleanly, so that someone who has left retains no access to, and no standing power within, the organization.

The sequence needs to be explicit and confirmed: disable accounts and revoke sessions on departure, remove the person from privileged groups and shared accounts, reclaim the access accumulated across every role they held, rotate any shared secret they knew, recover devices and credentials, and record the disposition. Movers deserve the same discipline for the access their old role no longer justifies, which is the access reviews most reliably miss.

Audit the outcome by reconciliation: check departed and moved people against access still active in their name, membership of privileged groups, and shared credentials they knew that were never rotated. This reliably finds people offboarded on paper but not in practice — the still-active account, the standing privilege, the shared password never changed — which are a favored and long-lived route back in.