What the Programme Cannot Do

A programme that answers everything asked of it is answering some things badly. Defending the boundary is what keeps it trusted on the rest.

Whether an action was appropriate

Why not: the record shows what was done, not whether it should have been.

Use instead: the change record and the stated purpose of the session, which is why requests should carry a reason.

Whether a person is trustworthy

Why not: privileged access data describes actions, not intent, and treating it otherwise is both inaccurate and the fastest way to lose the cooperation of the people you depend on.

Use instead: normal management processes, and keep the security data out of them.

Whether the estate is fully covered

Why not: coverage is measured against an inventory that is itself incomplete.

Use instead: coverage stated against an independent asset register, with the known gaps named and a residual-risk list maintained.

Whether a breach was prevented

Why not: unfalsifiable. Nothing that did not happen can be attributed.

Use instead: exposure measures before and after, and rotation time measured by drill. Both are concrete and defensible.

What happened in cloud

Why not: most cloud administration is API activity with no interactive session to broker.

Use instead: platform audit logs, shipped somewhere the account administrators cannot alter.

What an attacker did on a compromised endpoint

Why not: actions through a legitimate session are recorded as legitimate.

Use instead: endpoint detection, and administrative workstation controls that reduce the likelihood.

Whether service accounts are safe to rotate

Why not: dependency mapping is empirical and never complete.

Use instead: authentication logging over a full quarter, a maintenance window, and a rollback plan. Accept residual uncertainty rather than pretending it away.

Application-level privilege

Why not: infrastructure-focused programmes rarely reach the finance system, the HR platform or the CRM, which hold the data an attacker wants.

Use instead: a separate stream working with each system owner, and include it in the inventory even where it is out of scope for the tooling.

How to decline

Say what the programme does support, which is usually adjacent and substantial.

Say what would answer the question and roughly what it would cost.

Write the limitation into the report itself, not the covering email, because the report is what circulates.

Do not produce a precise number you cannot support. It will be quoted without the caveat, and when it is wrong the whole programme's reporting is discounted.

What it does support

Who can obtain administrative access, and by what paths.

Who obtained it, when, and from where.

What was done in a brokered session.

How old every privileged credential is.

How long a full rotation takes.

Five things answered reliably is a programme worth funding, and defending the boundary is what keeps those five trusted.

The residual-risk list

The artefact that makes every coverage claim believable.

Systems that cannot be onboarded, with the reason and compensating controls.

Standing rights that cannot be removed, with justification and review dates.

The workstation gap, unless dedicated devices are deployed.

Application-level administration outside scope.

The broker itself as a concentration of risk.

Reviewed annually, reported alongside the coverage figures, and shrinking over time.

A programme without this list is claiming completeness it cannot support.

Saying no to a number

The specific skill that keeps the programme trusted, and it is a communication problem.

Name what you can answer, which is usually adjacent and useful.

Name what the question would require and roughly what it would cost.

Give a range where a range is honest, with the basis stated.

Do not produce a precise number with a caveat, because the caveat is dropped in the retelling.

Write the limitation into the report, not the covering email, since the report is what circulates.