Part II · Chapter 4 · What a control is · lesson 11
Your register, with the choices in it rather than the defaults
15 min
Builds on Leaving something out, in a sentence you would say to a customer
Part II · Chapter 4 · What a control is · lesson 11
15 min
Builds on Leaving something out, in a sentence you would say to a customer
Most control registers are a list somebody was given with a status column added on the right. Read one and you cannot tell which rows were decided and which were inherited, because both kinds of row look identical: a name, a status, an owner, a date.
The difference is in two fields that are usually empty. Why this one applies to you, in your own sentence. And why the ones you left out are out — not that they are out, which the blank row already says, but why, in a sentence you would say to a customer with a straight face.
This lesson is the register itself. Everything you have decided in this track is in it, and the referee will read it back.
Three things make a register yours rather than a copy.
A reason per inclusion. One sentence saying what about your organisation makes this control somebody's job. If the sentence is generic, the row was inherited.
A reason per exclusion. An exclusion with a reason is a decision. An exclusion without one is a gap somebody will find, and the blank looks exactly the same in both cases.
A status you would defend. In place and running are different claims, and the second one is about artefacts that exist inside a period.
What the register cannot hold is a figure for how far along you are. There is no field for it and nowhere to put one, because the only honest aggregate here is the count of things that contradict each other — and that number goes up as you get more honest.
Fill it in for the controls you decided about in this track, and for any others you have an opinion on. Where you have not decided, leave it undecided: that is an accurate entry and the referee can work with it. A row marked running because the policy exists is the one entry that makes everything downstream harder to trust.
Your own register
Nothing here is graded, and nothing here leaves your browser unless you are signed in. A filled-in register is an inventory of your known weaknesses, so keep the real one where your auditor can see it — this is somewhere to think.
One or two sentences, in your own words. The test is whether you would read it out to a customer.
Six facts about you
These decide which controls are even yours to argue about. The honest answer usually removes more than it adds.
The period you are claiming
Everything in here is measured against these two dates. Typed as year-month-day, so the same thing is stored whatever your browser thinks the date format is.
two dates, the second after the first
What could go wrong
A sentence with a victim in it, not a category. There is no score field here and there is nowhere to put one: the two bands are never multiplied.
Once a year or so
A customer notices
What will you do about it?
What you could hand over
Only what already exists, with a date on it. A policy is real evidence of design and no evidence at all of operation, which is why that is the second question.
What does it show?
Below is what does not line up. It is not a verdict and it is not a score. Each line is two things you wrote that cannot both be the case, phrased as the question somebody would ask about it.
What does not line up
Nothing yet, because there is nothing in here yet. An empty workspace has no contradictions and tells you nothing.
These are contradictions between things you wrote. Nothing here can tell you whether any of it is enough — that is a judgement, and it moves with the auditor, the boundary and the year.
Read the list looking for three specific shapes.
Running, with nothing attached. The most common one, and the one this whole track has been building towards. It does not mean the control is not happening. It means the register cannot show that it is, and the remedy is either an artefact or a more accurate status.
In place, and no risk of yours names it. Work being done that no assessment asked for. Two legitimate answers: write the risk you had in mind when you set it up, or record the obligation it came from — a contract, a platform requirement, a buyer's question. Both are decisions. Neither is reverse- engineering a risk to cover the row.
Excluded, with a reason that is about convenience. Read your own exclusion sentences out loud. The physical-security one is the classic: excluding it because there are no premises reads as reasonable and is backwards, since the absence of a building is the reason it applies — whatever a badge reader was doing has gone and nothing replaced it. If the sentence would not survive being quoted back to you by a buyer, it is not finished.
An empty findings list is worth a moment's suspicion. It usually means the register is thin rather than consistent: a workspace with four rows in it has very little opportunity to contradict itself, and the count rising as you add honest rows is the system working rather than failing.
The register you have just built is bigger than the one you will have in a year. That is not a defect of either; the useful habit is to notice which rows you are already slightly embarrassed by.
And one condition changes what the fields mean entirely. Where a control is inherited from a platform you do not operate — storage encryption, physical protection of a data centre, the availability of a managed database — your choice is not what to do. It is what to verify, how often, and what you would do if the verification came back wrong. The owner field then names whoever reads the provider's report rather than whoever performs anything, and a status of running says something quite different from what it says on a row you operate yourself. Write that distinction into the reason field; the register has no other place for it.
Check