Most security work fails in one of two directions. Either nothing is automated, so the control exists on paper and is skipped under pressure; or everything is automated, including the steps that carry consequence, and the first serious question from a supervisor has no human answer behind it.
The method is deciding, deliberately and in writing, which decisions are allowed to be automatic. Everything before that line is engineered to run without asking anyone. Everything after it stops, waits for a named person, and leaves a trace of what they decided and why.
That line is not a philosophy. It is drawn per engagement, per process, with you, and it is the first artefact we produce.
The shape of an engagement
Five stages, and an ending that is scoped from the start.
This is not discover-design-deliver with new labels. Each stage below has a condition for being finished and a specific thing that leaves our hands.
-
Orientation
We establish what is actually uncomfortable, what is in scope, and what evidence already exists. It ends with a written scope — or with a referral, if the honest answer is that this is someone else's work.
-
Evidence, not impression
We look at the running system rather than the document that describes it: configurations as deployed, pipelines as executed, registers as maintained. Findings come back sorted by what we confirmed, what we interpreted, what we assumed and what we could not establish — never blended into one confident tone.
-
The decision point
You decide what gets fixed, what gets accepted and what gets deferred. We bring the options and the trade-offs; we do not make the choice on your behalf. Each outcome is recorded with a name, a date and the reasoning behind it, in a form that survives the meeting.
-
Implementation
Work happens inside your change process, in your repositories, under your approvals. Where a control can be automated and evidenced automatically, it is. Where it cannot, we say so rather than papering over it with a document.
-
Handover and exit
The condition for finishing is that your team can run and evidence the thing without us. The exit is written into the scope at the beginning, not negotiated at the end.
Epistemic discipline
What we know, what we think, and where the line is.
The most expensive failure in this trade is not a missed vulnerability. It is a report whose confident paragraphs hide which parts were verified and which were inferred, so that a decision gets made on the wrong half. Every finding we hand over carries one of four labels.
- Confirmed
- Observed directly, with the method and the date recorded, and reproducible by someone else using what we wrote down.
- Interpreted
- A conclusion we drew from confirmed evidence. The evidence and the reasoning are both stated, so you can disagree with the step rather than with the person.
- Assumed
- Taken as true because it was not testable in scope. Every assumption is listed, with what would change if it turned out to be wrong.
- Not established
- What we could not determine, and why — no access, no window, no data. Recorded as unavailable rather than smoothed over, because a gap you know about is manageable and one you do not is not.
One consequence is worth stating plainly, because internal audit and supervisors both eventually ask it: assumptions never become evidence. Only confirmed findings populate a control assessment or a risk register. Anything interpreted, assumed or not established is carried as an open item with a route to closing it — tested, accepted with a name against it, or deliberately parked. What does not happen is an assumption quietly hardening into a fact somewhere between the draft and the final report.
An engagement that cannot end is not a service. It is a dependency.
We are a small practice, which means we cannot survive on retained confusion even if we wanted to. The work is scoped so that finishing is the success condition, and so that the thing we leave behind keeps working when we are no longer in the room.
The artefact
What the decision record contains.
Every consequential decision in an engagement produces one of these. It is the document your successor reads in two years, and the one that answers the question a supervisor eventually asks: who decided this, on what basis, and when?
- The question
- Stated as a decision, not as a topic, with the scope it applies to and the date by which it had to be made.
- Evidence register
- What was examined, how, and when — with each item labelled confirmed, interpreted, assumed or not established.
- Options and trade-offs
- The realistic alternatives including doing nothing, each with its cost, its effect on the risk, and what it forecloses.
- Residual risk and its owner
- What remains after the chosen option, expressed in terms of consequence rather than a colour, and the name of the person who accepted it.
- Open questions
- What is still unresolved and who has to resolve it. A decision record with no open questions is usually a decision record that stopped looking.
- Next actions and review date
- What happens now, who does it, and when the decision is revisited — because an accepted risk with no review date quietly becomes a permanent one.
The honest part
What the work needs from you.
These four are what actually stall work, so they belong on the page rather than in a change request three months in. None of them is unusual; all of them are easier to arrange before the engagement starts than during it.
A named counterpart
One technical person who knows the environment and can answer within a day. Not a committee, and not a distribution list.
Access that matches the scope
Read access to the systems in scope, granted at the start. Work that waits three weeks for a credential is work you paid for and did not receive.
A window where a real test can disrupt something
A failover that is never exercised is a document. Rehearsal needs permission to be inconvenient, agreed in advance.
Someone who can accept residual risk
A person with the authority to sign, available at the decision points. Every human approval point in the plan needs a name against it from day one.
Limits
What this approach is not.
We are an independent technical challenge, not an outsourced sign-off. We do not replace your governance, your risk function or your internal audit, and a decision record we help you produce is yours, made by your people.
We do not give legal advice and we do not represent you before a supervisor. Regulatory work here is technical, operational and regulatory in the practical sense — reading what applies to you and building what it requires — never an opinion on your legal position.
We are not a managed security service provider and we do not staff a 24/7 desk. We are aligned to ISO 27001 practice and we are not ISO 27001 certified; we accept the clauses of DORA article 30 as a supplier and we do not claim DORA compliance on our own behalf. If a proposal you receive from us ever reads otherwise, it is wrong and we will correct it.
Next step
Bring us the decision that cannot be made safely from a slide deck.
The most useful first conversation is not about our capabilities. It is about one decision you have to make, the evidence you currently have for it, and what is missing.
Regulation notes
Or start from what is on your desk.
The practitioner pages — dated, sourced, and written for engineers and risk officers rather than for search engines.