The layer most teams stop above.

• Access that accumulated: broad standing credentials granted at kickoff because scoping them was harder.
• A product about to be asked security questions by a customer's procurement process for the first time.
• An agent, job or integration whose permissions were inherited rather than decided.
• Behaviour the application logs cannot explain, where the answer is in the runtime, the kernel, the filesystem or the network.
• A system that needs hardening as a design decision rather than as a pass before launch.

A reference architecture, meaning the shape the work is designed to rather than a record of systems delivered. It names layers and responsibilities and never products: what runs at a given layer is a decision taken with you during scoping, not one taken here in advance.

• An access model: who and what may reach which system, at what privilege, for how long.
• Credential and secret handling, with secrets in your store and injected at runtime rather than committed or pasted.
• A threat review carried out while the system is being designed, not applied to it afterwards.
• Hardening decisions recorded with their reasoning, so a control can be reviewed instead of guessed at.
• Low-level and systems debugging: the traced cause, and the change that fixes it.
• An access and security checklist, filled in for the engagement and handed back at the end.

• Broad standing access granted at kickoff because scoping it properly was harder.
• Credentials in source, in a chat thread or in a ticket, where they outlive the person who put them there.
• A blast radius that was inherited from a convenient credential rather than decided by anyone.
• A check that fails open, so an unreachable dependency becomes an unnoticed bypass.
• A recurring failure nobody can explain, where the investigation stops at the application boundary.

• Compliance certification. No SOC 2 or ISO 27001 audit is offered or held, and a consultancy that sells the certificate is a different business.
• Penetration testing as a deliverable. Independent testing should be independent; this builds and reviews the system rather than attesting to it.
• A security review with no authority to change anything, where the report is the product and nothing is fixed.
• Incident response retainers. There is no team on call, and promising a response time nobody can staff would be worse than declining.
• Anything that needs a security claim published before it is true. What gets stated is the practice, and it is on /security to be checked.

1. 01

   The access list, and its return

   What was issued, to what, at what privilege, and when it was handed back. Access is requested per system rather than granted broadly at the start, which is what makes returning it a checklist rather than an archaeology exercise.

2. 02

   Secrets in your store, never ours

   Credentials live in your secret manager and are injected at runtime for the whole engagement. There is no migration step at the end because they were never anywhere else.

3. 03

   The decisions, with their reasoning

   Every control traced back to why it exists, so your team can review it rather than inherit it. A boundary whose reason is lost is a boundary that eventually gets widened by someone being helpful.

4. 04

   The cause, not just the fix

   Where the work was an investigation, what was actually happening and how it was established, so the next occurrence is recognised rather than re-investigated from scratch.

• PolicySecurity practicesThe stated engineering practice: access, credentials, deploy paths, data boundaries, agent permissions and handover.
• BuildA privilege-separated display managerThe operating-system build, and the evidence that the work genuinely continues below the application layer.
• ArticleChoosing an init systemA systems decision argued in full, including what it cost, as a sample of how this reasoning is done.