Part II · Chapter 2 · The Boundary · lesson 3

Inside the line means somebody will ask you about it

10 min

Builds on The sentence everybody copies, and what it quietly commits you to

A team put their staging environment inside the boundary. The reasoning took about ninety seconds and was not foolish: staging is built from the same templates as production, it is patched by the same pipeline, and leaving it out looked like hiding something.

Nine months later, somebody is exporting the staging access list every quarter, chasing an approval for a staging change that happened at eleven at night, and explaining in writing why the staging backup restore test was skipped in February. None of that work makes staging safer. All of it exists because of ninety seconds in a meeting.

Predict

That team added one environment to the boundary. What did they buy for the hours it now costs them?

A stronger report, because more of the estate was examinedNothing a buyer can see, and three evidence streams somebody now ownsProtection against a buyer noticing that staging was excludedA faster audit, because the systems are similar and the evidence is shared

Inclusion is not a claim about quality. It is a commitment of hours.

A system inside the boundary is a system whose controls are described, whose evidence has to exist for every instance in the period, and whose gaps are findings rather than private knowledge. A system outside the boundary is a system about which the document says nothing — which is a cost of a different kind, paid in a conversation with a buyer rather than in quarterly work.

Nothing in either framework rewards you for enclosing more. The reward for inclusion is that one specific question has an answer. The price is every control, every instance, for the whole window.

Not the same thing

A system you would describe as well run

An adjective, applied by the people who built it, usually correctly. It describes the state of the system today and the intentions of its owners.

Measured in: Judgement, held by someone who knows the system. No unit, no period, no population.
For example: Staging is built from the same templates as production and patched by the same pipeline.
Chase it alone and: Optimising this alone produces a company that is genuinely careful and has nothing dated to hand anybody, because nobody asked what the carefulness produces.

A system inside the boundary

A population. Every control you described as covering it owes an artefact for every instance in the period, produced at the time rather than assembled afterwards.

Measured in: Dated artefacts per control per period, and the number of instances the cadence implies.
For example: Four quarterly access exports for staging, dated inside the window, with the reviewer named on each.
Chase it alone and: Optimising this alone produces a company that can evidence everything and has quietly stopped asking whether the controls address anything.

Which is which? Put each one on a side.

The staging environment uses the same hardened base image as production
Somebody exported the staging access list on the last working day of each quarter and named who they removed
Nobody has ever found customer data in staging
The February restore test for staging did not happen, and the reason is written down
The staging deployment pipeline requires a second approver, enforced by the tool
The team that owns staging is the same team that owns production, so the standards are the same

What inclusion actually costs, in units

Three questions price it, and they are the same three every time.

How many controls would claim to cover it? Not how many exist — how many of the ones you described would a reader expect to apply here. Access review, change approval, logging, backup, vulnerability handling: five is ordinary for an environment.

How many instances does each one owe over the period? A quarterly control over nine months owes three. Five controls at three instances each is fifteen artefacts, per system, per period.

Who produces them? This is the question that decides whether the hours are real. If the artefact falls out of a pipeline the team already runs, the marginal cost is close to nothing. If somebody has to remember, the marginal cost is a recurring calendar invite and a person who did not ask for it.

The staging decision was wrong on the third question and nobody asked it. The exports are manual, the owner is one engineer, and the February gap happened because she was on leave.

Check

A reader of your report finds no mention of staging anywhere. What has the document told them about it?

That staging was examined and found acceptableThat staging has no controls on itNothing at all, which the reader will fill in according to what they already assumeThat staging is outside the boundary

Worth remembering

Inclusion is a commitment of hours, not a declaration that the system is well run; no reader counts your systems.
Price a system by three questions: how many controls would claim to cover it, how many instances each owes over the period, and who produces them.
The third question decides whether the hours are real — evidence that falls out of a pipeline is nearly free, evidence somebody has to remember is a recurring job.
The one honest argument for inclusion is shared owner, shared control, shared evidence — and it has to be checked rather than assumed.
Silence about a system is not an exclusion; it is a gap the reader fills in from what they already assume.