40 documents, 4 approvals, 0 readers.

Monday, 9:00 AM: forty policies in three minutes

Tom Bergeron starts as a backend developer. Farah's onboarding email is friendly and efficient:

Before you get your laptop, please read and acknowledge the security policies on the shared drive. There are 40. Tick the box in the onboarding form when you're done.

The onboarding form records a timestamp per policy. Tom's 40 timestamps span 3 minutes and 42 seconds.

That's 5.5 seconds per document. Nobody is going to pretend that's reading. Tom isn't lazy; he did exactly what the process asked him to do, which was tick boxes.

Here's the part that matters for you: those 40 acknowledgments are now your evidence that Wayne communicates its policies. An auditor will look at the timestamps and reject it, and they'll be right to.

40 "read and understood" ticks, 5.5 seconds apart.

11:20 AM: the question the policies can't answer

Tom pings you 2 hours later with an entirely reasonable question:

I'm debugging a customer's failed import. Can I paste the error log into the AI assistant our team uses? And can I use my own laptop until mine arrives?

You go looking for the answer.

On the laptop question, Wayne has two policies that disagree. The Equipment Use Policy from 2019 says company devices only, no exceptions. The Remote Work Policy from 2020, written in a hurry, allows personal devices "provided antivirus is installed."

On the AI question, 40 policies say nothing at all. Not "no." Nothing.

So Tom gets his answer from the only source available: whatever the person next to him does. That is what an unwritten policy looks like in practice, and it's also what the last 3 posts kept pointing at. The assurance map had a column for "the rule," and half the rows said nobody wrote one.

Two policies disagree, 40 say nothing, so the answer comes from the desk next door.

The unpopular truth: a policy nobody can find or understand isn't a weak control. It's an unwritten rule with a document attached, and the document makes it worse, because now you've told an auditor what you claim to do.

What's actually in the 40?

Before rewriting anything, inventory what's there. Start with the metadata, which takes a minute.

Get-ChildItem "\\wayne-fs01\Shared\Policies" -Recurse -Include *.docx,*.pdf |
  Select-Object Name, LastWriteTime,
    @{n='AgeYears';e={[math]::Round(((Get-Date) - $_.LastWriteTime).TotalDays / 365, 1)}} |
  Sort-Object LastWriteTime | Format-Table -AutoSize

Name                                   LastWriteTime       AgeYears
----                                   -------------       --------
Fax_and_Telephone_Use.docx             2018-03-12 10:41         6.6
Equipment_Use_Policy.docx              2019-06-04 16:22         5.4
Remote_Work_Policy_FINAL_v2.docx       2020-04-02 22:07         4.6
Copy of Password_Policy.docx           2021-02-18 09:15         3.7
Password_Standard_v3.docx              2021-02-18 09:51         3.7
...
Incident_Response_Plan.docx            2021-11-09 14:30         3.0

Sample output (illustrative). Wayne Industries is fictional.

Then read what's inside them.40 documents is an afternoon with coffee, and it's worth doing by hand, but a quick scan tells you where to look first.

# pip install python-docx
import glob, re
from docx import Document

FLAGS = {
    "placeholder": r"\[Insert|\[Company Name\]|<Your Company>|XXX",
    "dead tech":   r"(?i)fax|blackberry|on-?prem(ise)? exchange|CD-ROM",
    "no owner":    r"(?i)owner:\s*$|approved by:\s*$",
}

for path in glob.glob("policies/*.docx"):
    text = "\n".join(p.text for p in Document(path).paragraphs)
    hits = [name for name, pattern in FLAGS.items() if re.search(pattern, text)]
    if hits:
        print(f"{path.split('/')[-1]:45} {', '.join(hits)}")

Acceptable_Use_Policy.docx                    placeholder, no owner
Fax_and_Telephone_Use.docx                    dead tech
Equipment_Use_Policy.docx                     dead tech, no owner
Mobile_Device_Policy.docx                     placeholder, dead tech
Data_Retention_Policy.docx                    no owner

Sample output (illustrative). Wayne Industries is fictional.

The tally for Wayne's 40:

What 40 inherited documents actually contained.

Policy, Standard, Procedure, Guideline

Most policy sets are bad because everything got written as a "policy." 4different document types got merged into one, so the document is both too vague to follow and too detailed to survive a year.

Why this matters practically: when NIST changed its password advice, a company with a password standard updated one page and the control owner signed it. A company with a password policy needed a management approval cycle to change a number, so it didn't, and kept 90-day rotation for four more years.

Put obligations in policy. Put numbers in standards. Put clicks in procedures.

One of these needs the CEO's signature. Three don't.

What the standards actually ask for

Less than you'd think, and more specifically than you'd think.

ISO 27001 Clause 5.2 names exactly one document: the information security policy, established by top management. There's no required list beyond that.

Annex A 5.1 is where the set comes from. It asks for the information security policy and topic-specific policies to be defined, approved by management, published, communicated to and acknowledged by relevant personnel and relevant interested parties, and reviewed at planned intervals and if significant changes occur. Which topics you need comes out of your risk assessment and your Statement of Applicability, not out of a vendor's list of 40.

NIST CSF 2.0 GV.PO-01 and GV.PO-02 ask for policy that is established, communicated and enforced, then reviewed and updated when requirements, threats, technology or mission change. The implementation examples in the CSF explicitly include requiring people to acknowledge receipt when first hired, annually, and whenever a policy is updated.

SOC 2 CC5.3 expects control activities to be deployed through policies that establish what's expected and procedures that put them into action.

PCI DSS v4.0.1 12.1.1 and 12.1.2 want a security policy that is established, published, maintained and disseminated, and reviewed at least once every 12 months.

Notice what none of them say: "have 40 documents."

The published template: SANS

Don't write policies from a blank page. The SANS Institute publishes a free library of information security policy templates, around 30 of them, covering acceptable use, password construction and protection, remote access, email, disaster recovery, web application security and more. They're plain, short and deliberately editable.

https://www.sans.org/information-security-policy

Two rules when you use them.

Delete more than you add. The SANS templates cover situations Wayne doesn't have. Every clause you keep is a clause an auditor can test you against. A policy that says "we log all privileged activity and review it weekly" is a finding waiting to happen if nobody reviews anything weekly.

Replace every example with your own environment. If the document still says [Insert Company Name], it tells the auditor exactly how much thought went into it. 5 of Wayne's 40 failed on this alone.

Wayne's first policy set: 9 policies, 4 standards

Each one exists because a specific thing went wrong in the last 8 weeks, not because it appeared on a list.

And the four standards that sit under them:

The AI assistant question lands in Acceptable Use, with one clear paragraph: approved tools only, no customer data or credentials in prompts, and a named person who can approve a new tool. The laptop question lands in the Endpoint Standard, and the 2019 and 2020 documents that disagreed are retired the same day.

9 policies, 4 standards, one owner each.

The unpopular truth: the right number of policies is the smallest number you can keep current. 12 documents that are reviewed and followed beat 40 that are complete and ignored, and no auditor has ever given credit for volume.

What happened to the other 27

Retiring documents is the part people skip, and it's the part that reduces risk immediately. An obsolete policy is a live obligation until you formally kill it.

Every retired document gets a line in a retirement log: file name, date retired, who approved the retirement, and where it went. That log is evidence too. It's how you answer "what happened to the Fax and Telephone Use Policy?" without shrugging.

40 in, 13 out, and a retirement log for the rest.

The anatomy of a policy that gets used

Every document in the set has the same 11 fields. The first 6 are the document; the last 5 are what makes it auditable.

Two more rules Wayne adopted. Keep each policy under two pages, because length is the enemy of reading. And write statements people can actually check: "production changes require approval from a second engineer" is testable, "employees should exercise appropriate care" is not.

Fixing the acknowledgment problem

40 ticks in 3 minutes was the symptom. The cure isn't a longer form.

• Assign by role. Tom gets the umbrella policy, Acceptable Use, the Endpoint Standard and Secure Development. 4 documents, not 40. Farah gets a different 4.

• Acknowledge at hire, annually, and on change. That's straight out of the CSF implementation examples, and it's also what an auditor samples against.

• Keep the record in one place, with the policy version number attached. "Acknowledged Acceptable Use v2.1 on 12 November" is evidence. "Acknowledged the policies" is not.

• Make one thing memorable. A 10 minute walkthrough in week one beats any number of ticks, and it means new joiners know who to ask.

Tom re-acknowledges his 4 the following week, with a version number against each, having actually read 8 pages.

4 documents, versioned, read in an hour instead of ticked in 3 minutes.

Evidence #9

By Friday, the folder holds:

• The Information Security Policy, one page, approved and signed by Maya, dated.

• 8 topic-specific policies and four standards, each with an owner, an approver and a review date.

• The policy register: 13 live documents, version, owner, approval date, next review.

• The retirement log for the 22 archived documents.

• Per-role acknowledgment records, with versions, starting with Tom's 4.

Evidence #9: an approved, owned, versioned policy set that matches how Wayne actually works.

One signature that means something, instead of 40 ticks that don't.

What an auditor accepts vs rejects

What you actually do on Monday

1. List every policy document you have, with its last modified date and its owner. Most teams are surprised twice.

2. Open the five oldest. Look for dead technology, placeholders and obligations nobody performs.

3. Find the contradictions. Passwords, devices and data retention are where they hide.

4. Write the umbrella policy first, one page, and get it signed by whoever is top management in your company.

5. Pick your topic list from your risks, not from a template index.

6. Retire the rest formally, with a log. Don't just leave them there.

7. Reassign acknowledgments by role, with version numbers.

Framework mapping

Every framework asks for a policy set. None of them asks for 40 documents.

Maturity ladder

At 20 people, "the policy set" is often one document with headings and a signature page, and that is genuinely fine. What's not fine is forty inherited documents nobody has read.

Where Wayne sits: 13 live documents, all owned, all approved, all dated this month. The review cycle starts next quarter, and the real test is whether anyone reaches for them the next time a question like Tom's arrives.

Cheatsheet

The policy set, on one page.

The takeaway

Write the smallest set you can keep current, and kill the rest formally. Put obligations in policies, numbers in standards, and clicks in procedures. Acknowledgment means a named person, a specific version and a date. If a policy says something Wayne doesn't do, it's not documentation. It's a finding you wrote yourself.

⚠️ This content is for educational purposes only. Wayne Industries is a fictional company. Nothing here is legal, audit, or compliance advice, validate against your own auditor and jurisdiction.

3 lines, drawn honestly.2 of them are the same person, and one is empty.

Friday, 9:10 AM: "Who reviews you?"

Gotham Mutual's analyst sends the 3 questionnaire items she couldn't close on Thursday. 2 are easy. The third isn't:

Is your information security programme reviewed independently of the people who operate it? Please describe the function, its reporting line, and the date of the most recent review.

You start typing an answer about the leaver test you ran and signed. Then you stop, because you can see what it says. You wrote the rule. You ran the test. You wrote up the result. The only person who checked any of it is you.

Dan reads the question over your shoulder.

"So the answer is 'me'," you say.

"Which means the answer is 'nobody'," he says.

Forty minutes later it gets worse, in the most useful way possible.

The one question on the questionnaire you can't answer with a document.

9:50 AM: the number that was wrong

On Wednesday you sent Dan an MFA coverage figure for the board pack: 62%, up from 30% at the start of the year.

On Friday morning Priya is building an alert for accounts without MFA, and she reruns the count herself. She gets 54%.

Her message: are we counting the same people?

You weren't. Your query counted enabled users in the Staff OU. Hers counted every enabled human account in the domain.

# Wednesday's number
$enrolled = (Get-ADGroupMember "MFA-Enrolled").Count
$staff    = (Get-ADUser -SearchBase "OU=Staff,DC=wayne,DC=example" -Filter 'Enabled -eq $true').Count
"{0} / {1} = {2:P0}" -f $enrolled, $staff, ($enrolled / $staff)

118 / 190 = 62%

Sample output (illustrative). Wayne Industries is fictional.

# Friday's number: every enabled account that belongs to a person
$people = Get-ADUser -Filter 'Enabled -eq $true' |
  Where-Object { $_.DistinguishedName -notlike "*OU=ServiceAccounts*" }
"{0} / {1} = {2:P0}" -f $enrolled, $people.Count, ($enrolled / $people.Count)

$people | Group-Object { ($_.DistinguishedName -split ',')[1] } |
  Select-Object Count, Name | Sort-Object Count -Descending

118 / 219 = 54%

Count Name
----- ----
  190 OU=Staff
   14 CN=Users
   12 OU=Contractors
    3 OU=Admins

Sample output (illustrative). Wayne Industries is fictional.

The gap isn't a rounding error. It's 29 people: contractors, 3 admin accounts, and 14 accounts still sitting in the default Users container because nobody ever moved them into an OU.

Those 29 are exactly the accounts an attacker would want. Your number excluded them because the query was written by the person whose number it was.

Nobody did anything dishonest. That's the point. The error survived because there was no second pair of eyes between the query and the board pack.

Same control, two people, two answers.

What the number counts, and what it quietly left out.

The unpopular truth: self-review failures almost never look like fraud. They look like a query written in a hurry by someone who already knows what the answer should be.

What the three lines actually are

The model most people half-remember is the Three Lines of Defence. The Institute of Internal Auditors published it in 2013 and replaced it in July 2020 with the Three Lines Model. The IIA dropped the word "defence" on purpose, because the model is about creating and protecting value, not about holding a wall.

Here's the shape of it, in plain terms:

• The governing body. The board, or whoever plays that role. Accountable to stakeholders for oversight. Sets the tone, provides resources, and establishes an independent internal audit function.

• Management: first line roles. The people who deliver the product and run the systems, and who own and operate the controls that go with them.

• Management: second line roles. People who provide expertise, set the rules, monitor, and challenge the first line. Security, risk, compliance, privacy.

• Internal audit: third line roles. Independent, objective assurance and advice on whether governance and risk management actually work, reporting to the governing body.

• External assurance providers. Certification bodies, SOC 2 auditors, penetration testers, regulators. They sit outside the model and can supplement it, not replace it.

The first and second lines both sit inside management, and the IIA expects them to blur in places. What must not blur is the third line's independence from management, because that's where its objectivity, authority and credibility come from.

Think of a restaurant. The kitchen cooks (first line). The head chef sets the recipes, checks the fridge temperatures and refuses dishes that aren't right (second line). The health inspector doesn't work for the chef (third line, roughly). If the chef inspects the chef, the sticker in the window means nothing.

Who does what, and who they answer to.

Wayne's lines, drawn honestly

Two problems fall out of that table.

One: for some controls, you are the first line as well as the second. MFA is the clearest case. You own it, you operate it, and you report on it. That was flagged when the ownership list was built, and this week it produced an actual wrong number.

Two: there is no third line at all. So the honest answer to Gotham's question is: nobody reviews the security programme independently, and the last review was never.

First line, second line, and an empty chair where the third should be.

The unpopular truth: at 240 accounts and one security person, a real three-line structure is a fiction. What isn't a fiction is the rule underneath it: nobody marks their own homework on anything that leaves the building.

What the standards actually require

The frameworks don't ask for three departments. They ask for independence at specific moments.

ISO 27001 Clause 9.2 requires internal audits at planned intervals, and requires you to select auditors so the audit process is objective and impartial. Certification auditors read that as a simple test: you cannot audit your own work. The person who built the ISMS cannot audit it.

Annex A 5.35 asks for the approach to information security to be reviewed independently at planned intervals and when significant changes happen.

Two useful facts for small teams. Internal audit can be outsourced, and the standard doesn't require you to employ an auditor. But your certification body cannot perform your internal audit for you.

SOC 2 expects the board or its equivalent to exercise oversight independent of management, and expects evaluations that are separate from the operation of the controls.

PCI DSS v4.0.1 Requirement 12.4.2 is the bluntest of all. For service providers, reviews at least once every three months must be performed by personnel other than those who perform the task being reviewed.

That last one is worth copying even if PCI never applies to you. It's the whole idea in one sentence.

Buying independence when you're small

You have four options. Most small companies end up using three of them at once.

1. Swap the reviewer inside the company. The operator and the reviewer are different people, even if both sit in the same 12-person engineering group. Priya re-performs your numbers. You re-perform hers. It costs an hour a month.

2. Train someone genuinely uninvolved. Farah doesn't run any technical control, so she can review process controls offboarding, access requests, training records against a checklist, without judging the technology.

3. Outsource or co-source internal audit. A consultancy runs the ISO 27001 internal audit programme. It isn't cheap, but it's a fraction of a hire, and it produces the impartial report that Clause 9.2 wants.

4. Use external assurance as supplementary evidence. A penetration test and a certification audit are genuine independent evaluations. They are also narrow, and they work for someone other than your governing body. Count them, don't lean on them.

What all four have in common: the reviewer has to be able to say "this is wrong" without it costing them anything. That's what independence means in practice, and it's the thing an org chart can't prove.

Three ways to get a second pair of eyes when you can't hire one.

The artifact: an assurance map

The template here is the IIA's Three Lines Model paper.

https://www.theiia.org/en/

https://www.theiia.org/globalassets/documents/resources/the-iias-three-lines-model-an-update-of-the-three-lines-of-defense-july-2020/three-lines-model-updated-english.pdf

The paper gives you the roles. What you build from it is an assurance map: one row per control area, showing who runs it, who challenges it, and who independently checks it. Auditors and boards use assurance maps to find two things areas nobody assures, and areas three people assure while nobody fixes anything.

Field by field

Wayne before

Wayne after

One row per area. The interesting column is the one that used to be empty.

Two decisions came out of building it. Maya approved a budget for an outsourced ISO 27001 internal audit ahead of the certification work. And every metric that leaves Wayne board pack, questionnaire, customer report now gets re-performed by someone who didn't produce it, with both names on it.

The unpopular truth: your penetration test isn't your third line. It's one narrow evaluation, bought by the people it evaluates, covering a slice of your environment on one week of the year. Useful. Not assurance over your programme.

Evidence #8

By Friday afternoon, three things go in the evidence folder:

• The assurance map, approved by Dan, with the independence gaps written down rather than hidden.

• The corrected MFA figure: both queries, the defined population, the 29 accounts that were missing, and Priya's re-performance note.

• A one-line correction to Dan, copying Maya: Wednesday's 62% counted the Staff OU only. The real figure is 54%. Here's the population we'll use from now on.

Evidence #8: a documented independence structure, and a metric that was corrected before anyone outside Wayne saw it.

The answer to Gotham goes out the same afternoon, and it's the honest version: no internal audit function today; peer re-performance in place now; an outsourced internal audit scheduled; here's the map.

She replies with one line: this is a better answer than most of the "yes" answers we get.

Two names on every number that leaves the building.

What an auditor accepts vs rejects

What you actually do on Monday

1. Draw your real lines on one page. Names, not departments. Where one name appears twice, circle it.

2. List every number that leaves the company. Board packs, questionnaires, customer reports. Put a second name on each one.

3. Define the population for your top three metrics. Write down what's counted, what's excluded and why.

4. Pick your independence route for the coming year: swap reviewers, train someone uninvolved, or buy it.

5. Schedule one report to your governing body, even if your governing body is one person and the report is a page.

6. Write the gaps down. An honest gap with a plan beats a claim that falls apart in an interview.

Framework mapping

Independence, as each framework asks for it.

Maturity ladder

At 20 people the third line is one rule: the person who ran it isn't the person who checks it. Write that down and you've got something an auditor can test.

Where Wayne sits: second line real, first line named, third line bought rather than built, as of Friday. The governing body role is Maya's, and she's about to receive the first report that was ever written for her.

Cheatsheet

Three lines, one rule: nobody marks their own homework.

The takeaway

Independence isn't a department. It's whether anyone with no stake in the answer looks before the answer leaves. Draw your lines with names. Where one name appears twice, write down what compensates. Every number that goes to a board or a customer needs a second person's name on it. Small teams can buy a third line. They cannot skip it and still say "reviewed."

⚠️ This content is for educational purposes only. Wayne Industries is a fictional company. Nothing here is legal, audit, or compliance advice, validate against your own auditor and jurisdiction.

6 links from "we do this" to "here's the proof." 4 were broken, and the other 2 were weak.

Monday, 8:50 AM: "Show us, don't tell us"

The email from Gotham Mutual's vendor-risk team is short and polite.

Ahead of Thursday's walkthrough, please be ready to show that access was removed for everyone who left Wayne in the last 90 days, employees and contractors. We'd like the list of leavers, the date each person left, and the date their access was disabled.

You read it twice and relax a little. Offboarding has an owner now. Farah owns the trigger, and you do the removal. Everyone said "I accept." It's on the list.

Then you try to answer the actual question, and the morning goes sideways.

Farah exports 6 employee departures from the HR system in about 2 minutes. Good start.

"And the contractors?" you ask.

"Contractors aren't in HR," she says. "Finance pays them. Ask accounts payable."

You pull up the domain controller's Security log to grab the "account disabled" events. The oldest event in the log is eleven days old.

By 10 AM you know three things. Wayne does offboard people. Wayne can't prove it. And you're not yet sure it offboards all of them.

"Show us" is a much harder question than "Do you?"

What an evidence chain actually is

An auditor never takes your word for anything. They follow a chain.

Think of a parcel with tracking. "We shipped it" means nothing. The tracking page shows it was picked up, scanned at the depot, loaded on the truck and signed for at the door. If any scan is missing, you can't prove it arrived, even if it did.

Controls work the same way. For any control, the chain has 6 links:

1. Rule. Where is it written what should happen, and by when?

2. Trigger. What starts the control, and is there a complete list of those starts?

3. Action. Who does the work, and where is the request recorded?

4. Record. What system writes down that it happened, with a timestamp?

5. Review. Who checks that it happened correctly, and where is that check recorded?

6. Kept. Where does the proof live, and will it still be there when an auditor asks?

An evidence chain map is a document that lays out those 6 links for one control. It names the system, the person and the storage location for each link.

The auditor's job is to walk the chain from end to end. Yours is to walk it first.

Rule, trigger, action, record, review, kept. Break one and the chain doesn't hold.

The unpopular truth: a control that ran but left no record didn't run, as far as an auditor is concerned. "We always do that" is a statement, not evidence.

How an auditor walks the chain

Auditors have three ways to test a control. NIST SP 800-53A, the US government's guide to assessing controls, names them plainly:

• Examine: read documents and records. Policies, tickets, logs.

• Interview: talk to the people who run the control.

• Test: make the control do its thing and compare what happens with what should happen.

SOC 2 auditors work the same way, even if they use different words. So do ISO 27001 certification auditors.

For offboarding, the walk looks like this:

1. Ask for the population: every person who left in the period.

2. Check that the population is complete. Does it match other sources?

3. Pick a sample, or take all of them if the list is short.

4. For each person, compare the date they left with the date access was disabled.

5. Ask who reviews this, and see the record of that review.

Wayne's population was the first thing to break.

Walking Wayne's chain, link by link

Link 1, Rule: "promptly"

Wayne's access control policy is one of the 40 on the shared drive. It says access is removed "promptly" when someone leaves.

"Promptly" can't be tested. An auditor can't count days against it.

CIS Controls v8.1 Safeguard 6.2 asks for accounts to be disabled immediately upon termination. You propose a rule you can measure: access is disabled by the end of the person's last working day. Farah agrees. Dan approves it on Monday afternoon, by email.

That email is the rule, dated and approved.

Link 2, Trigger: half the population is missing

Farah's HR export has six employee departures in the 90-day window.

Accounts payable keeps its own spreadsheet of contractors. 3 contracts ended in the same window. None of them are in the HR system, so none of them ever triggered offboarding.

That's the most common break in any evidence chain. Population completeness means proving your list includes everyone it should. If the list is incomplete, a perfect test of that list proves nothing.

6 leavers in HR. 3 more in a finance spreadsheet nobody connected.

Link 3, Action: tickets, mostly

Offboarding requests go through Deskline, Wayne's support desk. 5 out of 6 employee departures have a ticket. One contractor account was disabled because Priya asked in a hallway. No ticket.

The account was still disabled on time. It just left no trail.

Link 4, Record: eleven days of memory

This is where you find the break that stings most. Windows writes Event ID 4725, "A user account was disabled," to the domain controller's Security log. That's your timestamped record.

Get-WinEvent -ListLog Security -ComputerName DC01 |
  Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount

Get-WinEvent -ComputerName DC01 -LogName Security -MaxEvents 1 -Oldest |
  Select-Object TimeCreated

LogName  LogMode  MaximumSizeInBytes RecordCount
-------  -------  ------------------ -----------
Security Circular           20971520       48213

TimeCreated
-----------
2024-10-24 06:12:41

Sample output (illustrative). Wayne Industries is fictional.

The log is 20 MB and set to circular, which means new events overwrite the oldest ones. On a busy domain controller, that's about eleven days. Nobody changed it, and nothing ships the events anywhere else.

CIS Safeguard 8.10 asks for audit logs to be kept for at least 90 days. Wayne keeps eleven.

For older disables, there's a second source. Active Directory records when each attribute last changed. Disabling an account changes userAccountControl:

Get-ADReplicationAttributeMetadata -Server DC01 `
  -Object "CN=Rashid Osei,OU=Staff,DC=wayne,DC=example" `
  -Properties userAccountControl |
  Select-Object AttributeName, LastOriginatingChangeTime, Version

AttributeName      LastOriginatingChangeTime Version
-------------      ------------------------- -------
userAccountControl 2024-09-19 14:07:22             3

Sample output (illustrative). Wayne Industries is fictional.

That's useful, but it only shows the last change to that attribute. If someone re-enables and disables the account later, the earlier date is gone. Treat it as supporting evidence, and pair it with the ticket.

The log that was supposed to be the record forgot everything older than 11 days.

Link 5, Review: nobody

Nobody ever compared "date left" with "date disabled." Not monthly, not ever. So nobody knew whether the control worked.

Link 6, Kept: "somewhere"

The tickets are in Deskline. The log was on DC01 until it wasn't. The HR export lived in Farah's downloads folder.

None of it was in one place, and none of it had a retention period.

The template: SCF Evidence Request List

You don't need to invent a format for this. The Secure Controls Framework (SCF) publishes a free Evidence Request List (ERL). It's a catalogue of the artifacts an assessor would reasonably expect for each control, mapped to SCF controls. The SCF says it can serve as a guidebook for other audits too, not just SCF assessments.

Get it from the SCF website, as part of the free SCF download. https://securecontrolsframework.com/

The ERL tells you what to hand over. It doesn't tell you where it comes from or whether it will still exist. So Wayne keeps the ERL's own columns and adds 6 chain columns to its copy.

Field by field

Wayne before

Wayne after

Same control, same owners. Now every link says where the proof lives.

The unpopular truth: most evidence is collected the week before an audit, from whatever still exists. That's why so much of it gets rejected. Evidence has to be designed into the control, not gathered after it.

The test: 9 people, 2 problems

With both lists joined, you test all nine leavers. 9 is small enough to skip sampling.

Contractor accounts first, since that's where you're least sure:

Get-ADUser -Filter 'Enabled -eq $true' `
  -SearchBase "OU=Contractors,DC=wayne,DC=example" `
  -Properties LastLogonDate, AccountExpirationDate |
  Select-Object SamAccountName, Enabled, LastLogonDate, AccountExpirationDate

SamAccountName Enabled LastLogonDate        AccountExpirationDate
-------------- ------- -------------        ---------------------
ctr.jlee          True 2024-09-24 16:48:03
ctr.mvarga        True 2024-10-18 15:21:37
ctr.dfarouk       True 2024-11-01 09:02:15

Sample output (illustrative). Wayne Industries is fictional.

ctr.dfarouk is a current contractor, which is fine. The other 2 contracts ended 41 days and 17 days ago. Both accounts still work, and Wayne's VPN signs people in with their AD account.

Neither account shows a sign-in after the contract ended. LastLogonDate can lag by up to 2 weeks, though, so you check the VPN logs too. Nothing there either.

You disable both accounts on the spot, with tickets. Then you set an expiry date on every contractor account, so the account shuts itself off even if nobody remembers.

The full result:

Row 3 happened because the ticket was raised 4 days after the person left. Rows 8 and 9 happened because contractors never triggered anything at all.

9 leavers, 1 late, 2 never done.

The unpopular truth: finding your own exceptions before an audit is the best result you can get. Exceptions you find and fix are a working control. Exceptions an auditor finds are a finding, and a question about everything else you told them.

Evidence #7

On Wednesday you put it together. It goes in Evidence/Access/Offboarding/:

• The chain map for offboarding: the ERL row plus Wayne's 6 chain columns.

• Dan's approval of the "end of last working day" rule, from Monday.

• The HR export and the accounts payable list, with the reconciliation note.

• The nine-row test sheet with all three problems written up: cause, fix and date fixed.

• Farah's sign-off on the test, and Dan's review on Wednesday at 5:15 PM.

Evidence #7: a complete, reconciled offboarding test with its exceptions disclosed and fixed.

"Do we tell Gotham?" "We tell Gotham."

Thursday, 2 PM: the walkthrough

Gotham Mutual's analyst asks for the leaver list first. You show both sources and the reconciliation.

She picks row 8 and asks why a contractor kept access for 41 days. You show the cause, the fix, the VPN check and the new expiry dates.

She asks how she'll know it keeps working. You show the monthly test, who signs it, and where the next one will be filed.

She writes down 2 things: a finding that was self-identified and fixed, and a request to see next quarter's test.

That's not a pass. But it's a conversation that can end in a signed contract, which "trust us" never is.

"You found these yourselves?" "Then fixed them. Here's the chain."

What an auditor accepts vs rejects

What you actually do on Monday

1. Pick one control that an auditor or customer is sure to ask about. Offboarding is a good first choice.

2. Write the six links for it on one page: rule, trigger, action, record, review, kept.

3. Find every trigger source. HR, finance, vendor contracts, the agency that hires your temps.

4. Check how long your records really last. Look at log size and mode, not the policy.

5. Run the test yourself. Last 90 days, every leaver, last day vs disabled date.

6. Write up what you find, including the ugly rows, and get the owner to sign it.

Framework mapping

Every framework wants the same thing: proof, not promises.

Maturity ladder

Be honest: at 20 people, the whole chain map is often one spreadsheet tab. That's fine, as long as every link has an answer.

Where Wayne sits: at the 200-person stage for one control, offboarding, as of Wednesday. Every other control on the list still needs its own chain map, and most of them have a link nobody has checked.

Cheatsheet

The evidence chain, on one page.

The takeaway

A control is only as strong as the weakest link between the rule and the stored proof. Prove the population is complete before you test anything in it. Check how long your records really last, not how long you think they do. Find your own exceptions first, write them down, and fix them.

⚠️ This content is for educational purposes only. Wayne Industries is a fictional company. Nothing here is legal, audit, or compliance advice, validate against your own auditor and jurisdiction.

Eighteen controls on Wayne's list, and not one owner who'd been told.

Monday, 9:05 AM: "Password resets are broken"

The first support ticket lands in Deskline at 9:05. By 9:40 there are 31.

Every one says the same thing: I clicked "forgot password" and nothing arrived.

Priya finds the cause in twenty minutes. MailRelay, the US service that sends Wayne's transactional email, stopped accepting Wayne's API key at midnight. The key was created in 2021.

Then she finds the warning. MailRelay sent it three weeks ago:

We're retiring API keys created before 2023. Rotate your key by Sunday or sending will stop.

It went to engineering@wayne-industries.example, a distribution list with 14 people on it.

Fourteen people received it. Several opened it. Nobody acted, because everybody assumed somebody else would.

Priya rotates the key, and resets start working again at 10:12. Nothing leaked. Customers were just locked out for a morning.

At 10:30, Dan walks over.

"Who owns MailRelay?"

You open the flow register you finished last week. Flow F4, transactional email to MailRelay, has a name in the owner column. But that owner decides whether customer data should go to MailRelay. Nobody owns the running of it: the key, the vendor notices, the renewal.

So you go looking for every other place Wayne has a name that doesn't mean anything.

Monday morning: 31 tickets, one expired key, and a warning 14 people saw.

Everyone owns it, so nobody does

Think of the sink in an office kitchen.

The mugs belong to everyone. So the pile grows until one person snaps and washes the lot. Then it builds up again, because nothing changed.

Security controls work the same way. A control is anything that reduces a risk: a setting, a process, a review. A control with "everyone" as its owner is that sink.

Psychologists call it the bystander effect: the more people who could act, the less likely any one of them does. A distribution list is a bystander machine.

That's what this post is about. The goal isn't a matrix with a name in every cell. It's a name that changes what happens when something goes wrong.

Everyone's mugs, nobody's dishes.

The unpopular truth: a team is not an owner. "Engineering," "IT" and "Security" can't be held accountable, can't be interviewed and can't reply to an email. If a cell needs a group name to look full, it's empty.

Wayne's list, honestly

You export Wayne's control list. It has 18 rows: the fixes and checks that came out of the first five weeks of this program. Each row has a "responsible" column that somebody filled in, mostly Dan, back when the goal was "don't leave it blank."

Here's the count.

csvcut -c "Current Roles and Responsibilities" wayne-csf-profile-current.csv \
  | tail -n +2 | sort | uniq -c | sort -rn

     11 Dan Okafor
      4 Security
      1 Engineering
      1 Everyone
      1 ""

Sample output (illustrative). Wayne Industries is fictional.

csvcut comes from csvkit, a free set of command-line CSV tools. It handles commas inside fields, which a plain cut doesn't.

Read those five lines again:

• Dan: 11. The CTO, who also runs engineering, hiring and the AWS bill.

• "Security": 4. That's you. There is one of you.

• "Engineering" and "Everyone": 2. Nobody.

• Blank: 1. Contractor VPN access after offboarding. It's been on Dan's worry thread since 2022.

The unpopular truth: if the CTO owns everything, the CTO owns nothing. A name repeated eleven times is a default, not a decision.

Owner, operator, backup: three different jobs

Most ownership confusion comes from one word doing three jobs.

The owner and operator can be the same person at a small company. They just shouldn't be the same person by accident.

You may know this as a RACI matrix: Responsible, Accountable, Consulted, Informed. RACI is a common project-management convention, not a security standard. Its one rule matters most: exactly one A per row. Two A's means two people who can each assume the other has it. That's how the MailRelay email died.

Three jobs, three names, one A per row.

The four-question test

A name in a cell is theatre until it passes four questions. Ask them out loud, to the person, not to the spreadsheet.

1. Do they know? Can the owner name the control without looking it up?

2. Can they act? Do they have the access, authority and budget to fix it when it breaks?

3. Do they have time? Is it realistic next to their actual job?

4. Will they notice? When the control fails, does a signal reach them rather than a shared inbox?

You book 15 minutes with Dan and read him his eleven rows.

He recognizes four. For three more, he says, "I think Priya does that." For the other four, he laughs.

That's not a failing on Dan's part. Nobody asked him. Someone typed his name because a CTO sounded safe.

Knows, can act, has time, will notice. Miss one and it's theatre.

Eleven rows with Dan's name. He recognized four.

Finding the bystander inboxes

The MailRelay notice went to a list with no owner. How many more are there?

Wayne's distribution lists live in Active Directory. AD groups have a managedBy attribute, which records who manages the group. You check the engineering list first.

Get-ADGroup -Identity "engineering" -Properties mail, managedBy, member |
  Select-Object Name, mail, managedBy, @{n='Members';e={$_.member.Count}}

Name        mail                                  managedBy Members
----        ----                                  --------- -------
engineering engineering@wayne-industries.example                 14

Sample output (illustrative). Wayne Industries is fictional.

Empty. Then every mail-enabled group with no manager:

Get-ADGroup -Filter 'mail -like "*"' -Properties mail, managedBy |
  Where-Object { -not $_.managedBy } |
  Select-Object Name, mail

Name              mail
----              ----
engineering       engineering@wayne-industries.example
all-staff         all-staff@wayne-industries.example
aws-notifications aws-notifications@wayne-industries.example
billing           billing@wayne-industries.example
it-alerts         it-alerts@wayne-industries.example
vendor-accounts   vendor-accounts@wayne-industries.example

Sample output (illustrative). Wayne Industries is fictional.

These commands need the ActiveDirectory PowerShell module (part of RSAT) and read access to the directory.

Six lists. Two of them, aws-notifications and vendor-accounts, are exactly where security and vendor warnings arrive.

Setting managedBy doesn't fix anything by itself. It's a pointer. The fix is that each list now has a named person who reads it, and each vendor account in the register has a named contact.

The template: NIST's CSF 2.0 Organizational Profile

You don't need to invent an ownership matrix. NIST publishes one inside a bigger tool.

The CSF 2.0 Organizational Profile template is a free spreadsheet from NIST. It's built for comparing where you are (Current Profile) with where you want to be (Target Profile), outcome by outcome. Among its columns are Current Roles and Responsibilities and Target Roles and Responsibilities. That's your ownership matrix, sitting next to the status and evidence for each outcome.

Get it from the "CSF 2.0 Profiles" page on NIST's Cybersecurity Framework site, where it's listed as the Organizational Profile template (XLSX). NIST's Quick Start Guide for creating profiles walks through filling it in.

https://www.nist.gov/cyberframework/profiles : NIST CSF 2.0 Profiles page

https://www.nist.gov/cyberframework/quick-start-guides : NIST SP 1301, CSF 2.0 Organizational Profiles Quick Start Guide

NIST says to customize the template. Wayne adds four columns to the Target side: Owner, Operator, Backup, and Owner acknowledged. One name per cell, no teams.

Field by field

Wayne before

Wayne after

The after table doesn't say any of these controls work yet. Backups are still untested. MFA is still at 30%. What changed is that each gap now has one person who knows it's theirs.

After the change, the count across all 18 rows looks like this:

csvcut -c "Owner" wayne-csf-profile-target.csv \
  | tail -n +2 | sort | uniq -c | sort -rn

      6 Priya Nair
      6 You (Head of Security)
      3 Dan Okafor
      2 Farah Haddad
      1 Maya Lindqvist

Sample output (illustrative). Wayne Industries is fictional.

Dan keeps three rows he actually decides: risk acceptance, the AWS account structure, and security resourcing (GV.RR-03). Maya keeps one: leadership accountability (GV.RR-01), which is hers whether she likes it or not. Farah Haddad, who leads People & Operations, takes offboarding and security in HR practices (GV.RR-04).

The same six rows, before and after. Names changed; status didn't. Proving the controls work is a separate job.

The unpopular truth: most ownership matrices are written for the auditor, not for the people named in them. If the owners have never seen the sheet, it's a costume.

Evidence #6

Getting names isn't enough. You need proof the names know.

On Tuesday you send each owner their rows, one email each:

You're listed as owner for the controls below. Owner means you're accountable for them working, you'll get the failure alerts, and you'll sign off the evidence. Reply "I accept," or tell me what's wrong with the assignment.

Priya, Dan and Maya reply "I accept" on Tuesday. Farah replies Wednesday with a question: does "owner" mean she removes VPN access herself? No. She owns the trigger; you do the removal. She accepts.

Dan pushed back on one row and moved it to Priya. That's the process working.

On Friday, Dan approves the Target Profile. The sheet, the four acknowledgment emails, your own signed note for your rows, and the managedBy changes go in the evidence folder together.

Evidence #6: dated, named and acknowledged ownership for all 18 controls.

Four replies, one approval, one folder.

What an auditor accepts vs rejects

ISO 27001 auditors and SOC 2 auditors both test ownership the same way: they read the document, then interview the person.

"Engineering." "Which person?"

What you actually do on Monday

1. Export your control list and count the names, like the uniq -c above. Anything over a third of the rows on one person needs a conversation.

2. Replace every team name with a person. If you can't pick one, you've found a real gap.

3. Run the four questions with each owner. Fifteen minutes each is enough.

4. Find your bystander inboxes. Check every shared list that receives vendor, cloud or security email, and give each one a named reader.

5. Get written acknowledgment. A one-line "I accept" reply is evidence. Silence isn't.

6. Set review triggers. Revisit the matrix when someone changes role or leaves, and at least once a year.

Framework mapping

Ownership, as each framework puts it.

Maturity ladder

At 20 people, a spreadsheet with the same name on every row is fine if that person knows and agreed. The problem is never the spreadsheet. It's the name nobody asked.

Where Wayne sits: at the 200-person stage on paper, as of Friday. Every row has one owner, an operator, a backup and a date. What's untested is whether the signals really reach the owners. The next vendor notice will show whether vendor-accounts works.

Cheatsheet

Control ownership, on one page.

The takeaway

A name in a cell is not ownership. A person who knows, can act, has time and gets the alert is. One accountable person per control. Teams and inboxes don't count. Get it in writing: a dated "I accept" beats a full matrix. Spread the load honestly, and write down where one person still carries too much.

⚠️ This content is for educational purposes only. Wayne Industries is a fictional company. Nothing here is legal, audit, or compliance advice, validate against your own auditor and jurisdiction.

One diagram from 2022, five boxes, and no arrows leaving AWS.

Monday, 8:47 AM: "Where else has it been?"

Dan forwards an email from Wayne's outside legal counsel. It's about prod-export-2024.sql.gz, the production export still sitting (locked now) in the staging bucket.

Counsel's question is short:

Before we can advise on whether this is reportable, we need to know every place this customer data goes, and every place a copy of it could have ended up.

Ten minutes later, a second forward. Gotham Mutual's questionnaire, question 58:

Provide a data flow diagram showing where customer data is stored, processed and transmitted, including subprocessors and their locations.

Two different people, the same question: where does Wayne's customer data actually go?

You open the wiki. The only diagram is architecture-v2.png, drawn in 2022. Five boxes: Browser, Load balancer, App, Database, Backups. Neat arrows. No staging. No vendors. Nothing ever leaves AWS.

You ask Priya if that's still accurate.

Priya: Roughly. You: Does customer data go anywhere that isn't on this picture? Priya: ...define "anywhere."

That's the week.

Counsel and a customer ask the same question. The wiki has five boxes.

What a data flow map actually is

A data flow diagram (DFD) shows how data moves: where it comes from, what touches it, where it's stored and where it leaves. It uses four shapes:

• External entity (or actor): a person or system outside your control. A customer, a vendor.

• Process: something that handles data. Your API, a background worker, a CI job.

• Data store: somewhere data rests. A database, a bucket, a backup, a spreadsheet.

• Data flow: an arrow showing data moving from one to another.

Then there's the fifth element, the one that makes the diagram useful for security: the trust boundary. It's a dashed line drawn wherever the level of trust changes. Internet to your network. Production to staging. Your company to a vendor. Canada to another country.

Think of an airport. Passport control and the security checkpoint are trust boundaries. Everything that crosses them gets checked: who you are, what you're carrying, whether you're allowed through. The airport is fine with people moving around. What it cares about is the crossings.

Data flows work the same way. A flow that stays inside production is one kind of risk. A flow that crosses a boundary needs answers: who approved it, is it encrypted, is there a contract, and does anyone know it exists?

And the thing that ruins airports is the same thing that ruins data flow maps: the staff door nobody put on the floor plan.

The unpopular truth: your architecture diagram is not a data flow map. An architecture diagram shows how the system is built. A data flow map shows where the data goes, including the ugly parts: the export someone ran once, the CSV in an email, the error tracker quietly collecting customer emails.

Nobody worries about the hallway. They worry about the doors.

The tool: OWASP Threat Dragon

You don't need to invent a diagram format. OWASP Threat Dragon is a free, open-source tool from the OWASP Foundation for drawing data flow diagrams with trust boundaries. It's built for threat modelling, but today you'll only use it to draw.

It runs as a desktop app (Windows, macOS, Linux) or as a web app you host yourself. Get it from the OWASP Threat Dragon project page or its GitHub releases.

https://owasp.org/projects/threat-dragon: OWASP Threat Dragon project page

https://github.com/OWASP/threat-dragon: OWASP Threat Dragon GitHub

Two things make it a good fit for a one-person security team:

1. The model is a JSON file. You can commit it to Git, review changes in a merge request, and query it from the command line.

2. Each element has security properties. A flow records whether it's encrypted and whether it crosses a public network. A store records whether it's encrypted or holds credentials. That turns a picture into something you can check.

Threat Dragon draws the map. The classification scheme from last week tells you which flows matter most. Anything carrying Restricted data gets drawn first, and gets drawn completely.

Four shapes and one dashed line. That's the whole notation.

Field by field: what Threat Dragon records

Wayne before

Data flow documentation: architecture-v2.png (2022), 5 boxes
Flows shown: 2 (browser to app, app to database)
Third parties shown: 0
Trust boundaries shown: 0
Countries shown: 0
Last reviewed: never
Approved by: nobody

Step 1: Watch, Read, Ask

There are three ways to find data flows, and you need all three. Each one misses things the others catch.

• Watch what's connected right now.

• Read the code and config for anything that sends data somewhere.

• Ask the people who move data by hand.

Start at the most sensitive store and work outward. For Wayne, that's the production customer database in wayne-prod, in AWS's Canada (Central) region.

Watch: who's connected, and who could be

psql -h wayne-prod-db.xxxxxxxx.ca-central-1.rds.amazonaws.com -U postgres -d appdb -c "
SELECT usename, application_name, client_addr
FROM pg_stat_activity
WHERE datname = 'appdb' AND usename IS NOT NULL;"

   usename    | application_name | client_addr
--------------+------------------+-------------
 wayne_api    | wayne-api        | 10.20.1.15
 wayne_api    | wayne-api        | 10.20.1.38
 wayne_worker | wayne-worker     | 10.20.2.9
(3 rows)

Sample output (illustrative). Wayne Industries is fictional.

That's today's connections. It only shows what's running right now. So ask a second question: who is allowed to log in at all?

psql -h wayne-prod-db.xxxxxxxx.ca-central-1.rds.amazonaws.com -U postgres -d appdb -c "
SELECT rolname FROM pg_roles WHERE rolcanlogin ORDER BY rolname;"

   rolname
--------------
 ci_refresh
 postgres
 wayne_api
 wayne_worker
(4 rows)

Sample output (illustrative). Wayne Industries is fictional.

ci_refresh isn't connected. It can log in anyway. Nobody on the 2022 diagram is called that.

Read: find what uses it

Search the code for the role name and the staging bucket:

cd ~/src/wayne-app
grep -rn -e "ci_refresh" -e "wayne-staging-data" --include="*.yml" --include="*.sh" .

./.gitlab-ci.yml:88:  refresh_staging:
./.gitlab-ci.yml:93:    - ./scripts/refresh-staging.sh
./scripts/refresh-staging.sh:9:PGUSER=ci_refresh
./scripts/refresh-staging.sh:14:aws s3 cp prod-export-$(date +%Y).sql.gz s3://wayne-staging-data/
./scripts/refresh-staging.sh:17:gunzip -c prod-export-$(date +%Y).sql.gz | psql "$STAGING_DB_URL"

Sample output (illustrative). Wayne Industries is fictional.

There it is. A CI job that dumps production, uploads the dump to the staging bucket, and restores it into the staging database. That's where prod-export-2024.sql.gz came from. And it means there's a second copy nobody had counted: the staging database itself.

Is the job still scheduled? GitLab's API will tell you:

curl --silent --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  "https://gitlab.wayne-industries.example/api/v4/projects/42/pipeline_schedules"

[
  {
    "id": 3,
    "description": "refresh staging from prod",
    "ref": "refs/heads/main",
    "cron": "0 2 * * 0",
    "cron_timezone": "America/Toronto",
    "next_run_at": "2025-01-05T07:00:00.000Z",
    "active": false,
    "created_at": "2024-03-11T15:02:41.000Z",
    "updated_at": "2024-03-18T09:12:05.000Z",
    "owner": { "name": "Priya Nair", "username": "priya.nair" }
  }
]

Sample output (illustrative). Wayne Industries is fictional.

Inactive. Priya confirms the story: she set it up in March 2024, it ran once, the staging restore broke half the test suite, and she switched it off. The job, the script and the ci_refresh credential stayed.

Priya: It's off. It's not a flow anymore. You: One click turns it back on. It's a flow.

A dormant flow still goes on the map. What matters is what can happen, not just what happened last week.

Switched off in 2024. Still one click from running.

Next, search for anything that sends data out of Wayne:

grep -rhoE "https://[a-zA-Z0-9.-]+\.[a-z]{2,}" config/ app/ | sort | uniq -c | sort -rn

     14 https://api.mailrelay.example
      9 https://ingest.tracelight.example
      6 https://api.deskline.example
      3 https://docs.wayne-industries.example

Sample output (illustrative). Wayne Industries is fictional.

Three vendors receive data straight from the app: a transactional email service (MailRelay), an error tracker (Tracelight) and the support desk (Deskline). They're 3 of Wayne's 12 unreviewed vendors. Their own documentation says MailRelay and Tracelight process data in the United States. Deskline hosts in Canada.

The error tracker deserves a closer look. Stack traces often include whatever was in memory when something broke. You open a recent Tracelight event and find a customer's email address in the request body. Nobody chose to send customer data to Tracelight. It just happens every time the app throws an error.

Read the cloud, too

Code isn't the only place flows hide. Infrastructure settings move data too:

aws rds describe-db-instance-automated-backups \
  --region us-east-1 \
  --profile wayne-prod \
  --query 'DBInstanceAutomatedBackups[].[DBInstanceIdentifier,Region,Status,Encrypted]' \
  --output table

-------------------------------------------------------------
|              DescribeDBInstanceAutomatedBackups           |
+-------------------+----------------+--------------+-------+
|  wayne-prod-db    |  ca-central-1  |  replicating |  True |
+-------------------+----------------+--------------+-------+

Sample output (llustrative). Wayne Industries is fictional.

Run in the us-east-1 region, this shows backups of wayne-prod-db, which lives in ca-central-1, being copied to the United States. Dan turned it on in 2023 for disaster recovery. It's a sensible setting. It's also customer data leaving Canada, and it isn't written down anywhere.

Ask: the flows no tool can find

Then you talk to people. The question that works best isn't "what systems do you use?" It's: "When did you last send customer information to anyone?"

Maya answers on Wednesday without looking up from her laptop:

Maya: Every quarter, marketing emails the web agency a list of customer contacts for the newsletter. You: As an attachment? Maya: A spreadsheet. Names, emails, company.

No code, no API, no log in AWS. A CSV, in an email, to an outside agency that runs its own AWS account (marketing-test) and has never had a security review.

The unpopular truth: the riskiest flows usually aren't in your code. They're in people's habits. Code search will never find a spreadsheet someone emails every quarter. You have to ask, and you have to ask the question in their words, not yours.

No API, no log, no diagram. Just a spreadsheet, every quarter.

Step 2: Draw the boundaries

With the flows found, the diagram almost draws itself. Wayne's map has four trust boundaries:

TB2 is the rule the classification scheme already implied. Last week's scheme said Restricted data lives in wayne-prod only. The map shows exactly where that rule was broken, and how.

Wayne's customer data, with every boundary crossing numbered.

Step 3: Turn the picture into a register

Threat Dragon saves the model as JSON, so you can pull every flow into a table and track decisions against it:

jq -r '.detail.diagrams[].cells[]
  | select(.data.type == "tm.Flow")
  | [.data.name, .data.protocol, (.data.isEncrypted|tostring), (.data.isPublicNetwork|tostring)]
  | @tsv' wayne-customer-data.json | column -t -s $'\t'

F1 Customer sign-in and app use               HTTPS             true   true
F2 API reads and writes customer records      PostgreSQL/TLS    true   false
F3 Automated backup replication to us-east-1  AWS internal      true   false
F4 Transactional email: name + email          HTTPS             true   true
F5 Error events with stack traces             HTTPS             true   true
F6 Support tickets                            HTTPS             true   true
F7 refresh-staging: prod dump to staging      pg_dump + S3      false  false
F8 Quarterly contact list to web agency       Email attachment  false  true

Sample output (illustrative). Wayne Industries is fictional.

Two false values in the "encrypted" column, and both are on flows nobody had drawn. That's not a coincidence. Undocumented flows are the ones nobody ever checked.

Step 4: Decide every crossing

The map tells you what exists. Dan, as the owner of customer data, decides what's allowed to keep existing. You sit down with him on Wednesday afternoon and go flow by flow.

Wayne after (approved by Dan, Wednesday)

A few things happen by Friday:

• Priya's merge request removes refresh_staging and the script. ci_refresh loses its login.

• Dan checks with counsel, who confirm the private staging database isn't needed for the exposure question. Staging is wiped and reseeded with fake data.

• Tracelight scrubbing is on. A forced test error arrives with [Filtered] where the email used to be.

• The original export (prod-export-2024.sql.gz) stays held, as before. Counsel now has the full map to work from.

• The diagram goes to Gotham Mutual for Q58, with the vendor names and countries listed.

Dan's written approval of the map, dated Wednesday, plus the merged change removing F7, become Evidence #5.

One map, eight decisions, one dated approval.

The unpopular truth: a data flow map is wrong the week after you draw it, unless something forces an update. Don't rely on "review annually." Tie it to change: a new vendor, a new integration, a new CI job that touches production. At Wayne, any merge request that adds an outbound URL or a production database role now needs a line in the map.

The flow register, before and after

Two flows on paper became eight flows with owners and decisions.

What an auditor accepts vs rejects

What you actually do on Monday

1. Pick your most sensitive data store. Start there, not with the whole company.

2. Watch: list live connections and every account that can log in.

3. Read: search code and config for outbound URLs, bucket names and database roles.

4. Read the cloud: check backup copies, replication and cross-region settings.

5. Ask: "When did you last send customer information to anyone?" Ask marketing, support and finance, not just engineering.

6. Draw it in Threat Dragon. Four shapes, plus dashed lines where trust changes.

7. Number every flow that crosses a boundary, and get the data owner to decide each one.

8. Tie updates to change, not just to the calendar.

Where data flow mapping lives in the frameworks

Every framework asks the same thing: know where the data goes, and who it goes to.

Maturity ladder

Be honest about the left column. At 20 people, a hand-drawn diagram with a date and an owner's "approved" email is a real control.

Where Wayne sits: Wayne now has a 200-person map for customer data only. Discovery was a one-off effort by one person, and nothing technical blocks a new outbound flow yet. The rule tying map updates to merge requests is brand new and untested.

Cheatsheet

Data flow mapping, on one page.

The takeaway

Your architecture diagram shows how things are built. A data flow map shows where the data goes. Find flows three ways: watch, read and ask. Each one misses what the others catch. Draw trust boundaries, and make the data owner decide every crossing. Dormant flows count, and so do spreadsheets in emails.

⚠️ This content is for educational purposes only. Wayne Industries is a fictional company. Nothing here is legal, audit, or compliance advice, validate against your own auditor and jurisdiction.

Zero labels, zero data owners, and two copies of customer data in places they shouldn't be.

Tuesday, 9:31 AM: "So what's actually in it?"

The closure of hackathon-2023 is still on hold. Last week's inventory found an RDS snapshot in that account called hack23-db-final. Postgres, taken in November 2023. Nobody could say what was inside.

Priya pings you again.

Priya: Can I kill the hackathon account yet? It's costing us money. You: Not until we know what's in that snapshot. Priya: It's demo data. Probably. You: "Probably" is what we said about the staging bucket.

She doesn't answer that one.

Because the staging bucket is the other loose end. The public access is blocked, but prod-export-2024.sql.gz is still sitting in wayne-staging-data. A production database export, in a staging bucket, that was public until a few weeks ago.

Then Dan forwards one more thing. Gotham Mutual's questionnaire, question 52:

Describe your data classification scheme and how it is applied to customer data.

Wayne doesn't have one. Not in the 40 policies on the shared drive, not in anyone's head.

So this week's job is simple to say and harder to do: decide what kinds of data Wayne has, what each kind is allowed to do, and then go look at those two files.

"Probably demo data" isn't a classification.

What data classification actually is

Data classification means sorting information into a few levels based on how much damage it would do if it leaked, got changed or disappeared. Each level comes with handling rules: where the data may live, who may see it, how it's protected and when it's deleted.

A label is how you mark which level a piece of data belongs to. On a document that might be a header. In AWS it's usually a tag.

Think of the care label inside a shirt. The label doesn't wash anything. It just tells whoever picks up the shirt what they're allowed to do with it: cold water, no dryer, don't bleach. Data labels work the same way. The label is useless on its own. What matters is the rule attached to it, and whether anyone follows it.

That's where most classification programs die. They pick labels, write a policy, and never connect the labels to anything people or systems actually do.

The unpopular truth: if everything is Confidential, nothing is. A scheme where 95% of files carry the top label tells people nothing, and they stop reading the label within a week.

When every file says Confidential, nobody reads the label.

Why it matters at Wayne right now

Classification isn't paperwork for its own sake. It's the thing that turns "is this bad?" into a question with an answer.

Take the staging export. Without a scheme, the conversation goes:

• Priya: it's just staging.

• Dan: but it came from production.

• You: does it have customer data?

• Everyone: no idea.

With a scheme, the conversation is one line: customer personal information is Restricted, and Restricted data never lives outside production. The export breaks the rule, full stop. No debate about which environment "counts."

The law points the same way. PIPEDA, the Canadian privacy law that covers Wayne's customer data, says safeguards must match how sensitive the information is. More sensitive information gets more protection. You can't do that if you haven't decided what's sensitive.

Wayne before

Data classification scheme: none
Policy covering classification: none (0 of 40 shared-drive policies)
Labels applied to any data: none
Named data owners: none
Rule for production data outside production: none

Wayne after (approved by Dan, Tuesday)

Three rules sit under the table. They do most of the work:

1. A copy is the same class as the original. An export, snapshot or backup of Restricted data is Restricted. Moving it doesn't downgrade it.

2. Label the system, not every file. Each system gets a default level. Everything inside it inherits that level unless the owner says otherwise.

3. When in doubt, go one level up for now, and ask the owner. The owner decides within five working days.

Four levels, each with a rule about where the data may live.

The unpopular truth: most people will never label a document by hand. Don't build a scheme that depends on them doing it. Put the label on the system, and let the system carry it.

Field by field: what each column is for

Step 1: find out what's in the snapshot

You don't open a two-year-old snapshot in place. You restore it to a temporary, private database, look at the structure, and delete the copy when you're done.

First, check the snapshot was never shared outside the account:

aws rds describe-db-snapshot-attributes \
  --db-snapshot-identifier hack23-db-final \
  --profile hackathon-2023

{
    "DBSnapshotAttributesResult": {
        "DBSnapshotIdentifier": "hack23-db-final",
        "DBSnapshotAttributes": [
            {
                "AttributeName": "restore",
                "AttributeValues": []
            }
        ]
    }
}

Sample output (illustrative). Wayne Industries is fictional.

An empty restore list means no other AWS account can restore it. If you ever see "all" in there, the snapshot is public, and that's a different, more urgent day.

Next, restore it to a private instance:

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier hack23-inspect \
  --db-snapshot-identifier hack23-db-final \
  --db-instance-class db.t3.micro \
  --no-publicly-accessible \
  --profile hackathon-2023

Then look at column names, not rows. You want to know what kind of data is there without reading anyone's personal details:

psql -h hack23-inspect.xxxxxxxx.us-east-1.rds.amazonaws.com -U postgres -d appdb -c "
SELECT table_name, string_agg(column_name, ', ') AS columns
FROM information_schema.columns
WHERE table_schema = 'public'
GROUP BY table_name ORDER BY table_name;"

   table_name    |                        columns
-----------------+--------------------------------------------------------
 customers       | id, full_name, email, phone, billing_address, created_at
 demo_widgets    | id, label, colour, created_at
 invoices        | id, customer_id, amount, issued_at
 users           | id, email, password_hash, last_login
(4 rows)

Sample output (illustrative). Wayne Industries is fictional.

demo_widgets is the demo. customers is not. Names, emails, phone numbers and billing addresses are customer personal information. Under the new scheme, that's Restricted, and it's sitting in a hackathon account.

So much for "probably."

Step 2: check the staging export the same way

Same idea. Read the table definitions, not the data. You can stream the file straight from S3 and only keep the CREATE TABLE lines:

aws s3 cp s3://wayne-staging-data/prod-export-2024.sql.gz - --profile wayne-staging \
  | gunzip | grep -E "^CREATE TABLE"

CREATE TABLE public.customers (
CREATE TABLE public.invoices (
CREATE TABLE public.subscriptions (
CREATE TABLE public.support_tickets (
CREATE TABLE public.users (

Sample output (illustrative). Wayne Industries is fictional.

Run this from an admin host you control, not your personal laptop. You're handling Restricted data now, even if you only keep the table names.

Same answer: a full copy of production customer data. Restricted, in staging. Rule 1 says the copy doesn't get a discount for living somewhere else.

A copy is the same class as the original, wherever it ends up.

Step 3: label the systems and the two files

Rule 2 says label the system. So the production database and each AWS account get a default level as a tag. Then the two problem files get their own tags, so anyone who finds them later sees what they are.

aws s3api put-object-tagging \
  --bucket wayne-staging-data \
  --key prod-export-2024.sql.gz \
  --tagging 'TagSet=[{Key=data-classification,Value=restricted},{Key=data-owner,Value=dan.okafor},{Key=decision-due,Value=see-register}]' \
  --profile wayne-staging

aws s3api get-object-tagging \
  --bucket wayne-staging-data \
  --key prod-export-2024.sql.gz \
  --profile wayne-staging

{
    "TagSet": [
        { "Key": "data-classification", "Value": "restricted" },
        { "Key": "data-owner", "Value": "dan.okafor" },
        { "Key": "decision-due", "Value": "see-register" }
    ]
}

Sample output (illustrative). Wayne Industries is fictional.

Before the tag, that same command returned an empty TagSet. That empty list is what "unclassified" looks like in AWS.

Tag names matter more than you'd think. Pick one key (data-classification) and four lowercase values, and write them into the policy. If one person tags Restricted, another RESTRICTED and a third sensitive, no automated check will ever work.

People skip the dropdown. Systems don't.

Step 4: decide what happens to each copy

A label tells you the rule. It doesn't make the decision. That's the data owner's job, and for customer data at Wayne that's Dan.

The two files get different answers, and the reason is worth spelling out.

The snapshot was never public and never shared. Nobody needs it: the hackathon ended two years ago, and production has its own backups. Dan approves deletion in writing on Thursday. You delete the snapshot and the temporary hack23-inspect instance, and save the confirmation. That approval, plus the before-and-after listing, becomes Evidence #4.

Priya can finally close the account.

The staging export is harder. It sat in a bucket that was public, and nobody had turned on access logging for that bucket. So nobody can prove who did or didn't download it. Whether that counts as a privacy breach Wayne must report is a question for Dan and legal counsel, not for a classification label.

So it isn't deleted yet. Deleting it now could destroy the only record of what was exposed. Instead:

• Access is limited to you and Dan through the bucket policy.

• It's tagged Restricted, with Dan as owner.

• Dan has the breach question in writing, with a date to decide by.

• Once counsel closes the question, it's deleted and the deletion is recorded.

The unpopular truth: the best classification decision is often deletion. Data you don't have can't leak, can't be subpoenaed and doesn't need a label. But you delete on purpose, with a record, and never while someone still needs to answer "what was exposed?"

One approval, one deletion, one dated record.

Step 5: the data inventory, before and after

Classification only works if it lands in your inventory. CIS Safeguard 3.2 asks for a data inventory based on your data management process, covering sensitive data at a minimum. Wayne's asset register from last week gets four new columns.

Four new columns turn a list of things into a list of decisions.

What an auditor accepts vs rejects

The auditor won't read your scheme. They'll pick a file and ask what it is.

What you actually do on Monday

1. Get the CIS Data Management Policy Template. Don't write your own from a blank page.

2. Pick three or four levels. Write one sentence of meaning and three real examples for each.

3. Write the copy rule. Exports, snapshots and backups keep the class of their source.

4. Name an owner for your most sensitive data. One person, in writing.

5. Label your systems, not your files. One tag key, fixed lowercase values.

6. Look for production data outside production. Check staging buckets, old snapshots and dev databases. Read column names, not rows.

7. Decide each stray copy on purpose: delete, move or hold. Keep the record.

8. Put a review date on the scheme. CIS asks for at least once a year.

Where classification lives in the frameworks

Every framework asks the same thing: know what's sensitive, and treat it that way.

Maturity ladder

Be honest about the left column. At 20 people, a spreadsheet column and an owner who answers emails is a real control.

Where Wayne sits: at about 240 accounts, Wayne is in the 200-person column on paper, with the scheme approved and the first tags applied. Discovery is still manual and nothing blocks the next export yet. That's a 20-person program with a 200-person policy, and that's fine for week four.

Cheatsheet

Data classification, on one page.

The takeaway

A classification scheme is only as good as the rule attached to each label. Label systems, not files, and make copies inherit their source's level. Read column names, not rows, when you go looking. Delete what you don't need, on purpose and on the record.

⚠️ This content is for educational purposes only. Wayne Industries is a fictional company. Nothing here is legal, audit, or compliance advice, validate against your own auditor and jurisdiction.

Seven accounts, 203 computers, 171 spreadsheet rows, and nobody who could say what any of it was.

Monday, 10:07 AM: "Closing it today, cool?"

Last Friday, Maya approved Wayne's scope. All seven AWS accounts are in it. Two of them, hackathon-2023 and old-sandbox, are marked "pending closure."

On Monday morning Priya sends you a message.

Priya: Closing hackathon-2023 today, cool? You: What's in it? Priya: The demo from the hackathon. Maybe a database? It was two years ago.

"Maybe" is the problem.

If that account holds a copy of real customer data, closing it without looking isn't a clean-up. It's destroying records you may need to explain later. And if it holds nothing, you still want a dated note that says so, because Gotham Mutual and an ISO auditor will both ask what happened to it.

So you reply: Hold off. Let's find out what's inside first.

That one question, "what's in it?", is the whole topic of this post.

"Maybe" isn't an inventory.

What an asset inventory actually is

An asset is anything that holds, processes or moves information you care about. Laptops, servers, cloud accounts, databases, software, and the data itself.

An asset inventory is the list of those things, with enough detail that someone else could find each one, and a named person who answers for it.

Think of a library. A pile of books isn't a library. A library knows what it has, where each book is, who has it checked out, and which ones are missing. The catalogue is what turns a pile into a library.

Most companies have a pile. Wayne's "catalogue" looked like this:

• A wiki page called AWS accounts, listing four of the seven.

• A laptop spreadsheet, laptops.xlsx, with 171 rows. Last edited in 2023.

• Active Directory, with 203 computer objects that nobody had compared to the spreadsheet.

• No list of installed software at all.

Three sources, three different answers, and no owner on any of them.

The unpopular truth: your inventory is wrong right now. Every company's is. The question an auditor cares about is whether you know how wrong it is, and what you do when you find out.

Why it comes first

Every other control starts with "for each asset."

Patch each server. Encrypt each laptop. Review access to each account. Back up each database. If an asset isn't on the list, none of those things happen to it. It just sits there, unpatched and unwatched.

That's exactly how Wayne ended up with a public bucket holding a production export. Nobody decided to leave it open. It simply wasn't on anyone's list, so no control ever reached it.

This is why CIS puts inventory at Control 1 and 2, and why the ISO 27001 auditor will ask for your inventory early.

Where unknown assets hide

You don't build an inventory by asking people what they own. You build it by pulling from systems that can't forget, then comparing.

At Wayne, you pull from five places:

1. AWS Organizations for every account.

2. Each account, every region, for what's running inside.

3. Active Directory for every domain-joined computer.

4. The laptop spreadsheet, for what the office thinks it bought.

5. The finance card statements, for anything paid for that no system reports.

No single source is complete. CIS says as much: there's rarely one source of truth, so you combine several and scan regularly.

Pull from systems that can't forget, then compare.

Step 1: what's inside the three accounts

You already have the account list from last week. Now you tag each account with an owner, so the answer lives in AWS and not only in your head.

aws organizations tag-resource \
  --resource-id 444455556666 \
  --tags Key=owner,Value=priya.nair@wayne-industries.example \
         Key=status,Value=pending-closure

aws organizations list-tags-for-resource --resource-id 444455556666 --output table

------------------------------------------------------------------
|                      ListTagsForResource                       |
+----------------------------------------------------------------+
||                             Tags                             ||
|+-----------+--------------------------------------------------+|
||    Key    |                      Value                       ||
|+-----------+--------------------------------------------------+|
||  owner    |  priya.nair@wayne-industries.example             ||
||  status   |  pending-closure                                 ||
|+-----------+--------------------------------------------------+|

Sample output (illustrative). Wayne Industries is fictional.

Then you look inside. The trap here is regions. A hackathon team in a hurry launches wherever the console happened to be pointing. So you check every enabled region, not just the one you use.

for r in $(aws ec2 describe-regions --profile hackathon-2023 \
            --query "Regions[].RegionName" --output text); do
  aws ec2 describe-instances --profile hackathon-2023 --region "$r" \
    --query "Reservations[].Instances[].[InstanceId,InstanceType,State.Name,LaunchTime]" \
    --output text | sed "s/^/$r  /"
done

us-east-1  i-0a1b2c3d4e5f60718  t3.large  running  2023-10-14T18:22:05+00:00
us-east-1  i-0f9e8d7c6b5a40312  t3.large  running  2023-10-14T18:24:41+00:00

Sample output (illustrative). Wayne Industries is fictional.

Two instances, running since the hackathon, in a region nobody at Wayne normally uses. Then the database check:

aws rds describe-db-snapshots --profile hackathon-2023 --region us-east-1 \
  --query "DBSnapshots[].[DBSnapshotIdentifier,SnapshotCreateTime,Engine]" \
  --output table

------------------------------------------------------------------------
|                          DescribeDBSnapshots                         |
+------------------+------------------------------------+--------------+
|  hack23-db-final |  2023-11-02T21:40:17.512000+00:00  |  postgres    |
+------------------+------------------------------------+--------------+

Sample output (illustrative). Wayne Industries is fictional.

Priya thinks the snapshot holds fake demo data. "Thinks" is not something you can write in an inventory. So the record says: contents unverified, do not delete.

The other two accounts turn up their own surprises:

• old-sandbox (Dan): one stopped instance, and an IAM user with an access key created in 2021 that is still active. Dan's reaction is exactly what you'd expect.

• marketing-test (the web agency): an S3 bucket and a live landing page from last year's campaign. The agency runs it. Nobody at Wayne was listed as responsible for it.

Three accounts, three surprises.

The unpopular truth: tag-based inventory only finds things that were tidy enough to be tagged. AWS's own tagging API returns resources that are tagged or were tagged at some point. The resources you're most worried about are the ones nobody ever tagged. Query the services directly.

Step 2: owner vs custodian

The marketing-test account raises a question that trips up a lot of teams: who "owns" something that an outside company runs?

Two roles help here:

• Owner: the named person at your company who is accountable for the asset. They decide whether it should exist, who gets access, and when it goes away.

• Custodian: whoever operates it day to day. That can be another team, or another company.

The agency is the custodian of marketing-test. But an outside company can't be your owner, because you can't hold them accountable inside your ISMS. So Dan, as CTO, becomes the owner, and the agency is recorded as custodian.

ISO 27001 A.5.9 asks for an inventory "including owners." It doesn't mean the person who touches it most. It means the person who answers for it.

The unpopular truth: an owner called "IT" is not an owner. A team can't be asked why something happened. A person can.

"We run it." "And I answer for it."

Step 3: reconcile the laptops

Now the dull part, which is where most of the real findings are.

You export every computer from Active Directory:

Get-ADComputer -Filter * -Properties OperatingSystem, LastLogonDate |
  Select-Object Name, OperatingSystem, LastLogonDate |
  Export-Csv .\ad-computers.csv -NoTypeInformation

$ad    = Import-Csv .\ad-computers.csv
$sheet = Import-Csv .\laptops.csv
Compare-Object -ReferenceObject $ad.Name -DifferenceObject $sheet.Hostname |
  Group-Object SideIndicator | Select-Object Name, Count

Name Count
---- -----
<=      45
=>      13

Sample output (illustrative). Wayne Industries is fictional.

<= means "in Active Directory, not in the spreadsheet." => means the reverse. So 158 computers match, and 58 don't.

You work through the 58:

Those last four matter most. Four laptops went home with people who no longer work at Wayne, and nobody asked for them back. That's ISO 27001 A.5.11, return of assets, failing quietly.

Remember Dan's 2022 worry thread about contractors keeping VPN access after they leave? It turns out it's not only access that leaves with people. It's hardware too.

158 match. 58 don't. Four have left the building.

This comparison is the actual control. A list on its own proves nothing. A list that gets compared against real systems, with the differences followed up, proves you're maintaining it. That's the "maintained" part of A.5.9.

Step 4: software, briefly

CIS Control 2 asks for the same thing for software: know what's installed, and make sure only supported software is on the approved list.

Wayne has no software list, so you start small. You take one standard laptop and pull what's installed as a baseline:

osqueryi --json "SELECT name, version, publisher FROM programs ORDER BY name LIMIT 3;"

[
  {"name":"7-Zip 23.01 (x64)","publisher":"Igor Pavlov","version":"23.01"},
  {"name":"Git","publisher":"The Git Development Community","version":"2.44.0"},
  {"name":"Google Chrome","publisher":"Google LLC","version":"124.0.6367.119"}
]

Sample output (illustrative). Wayne Industries is fictional.

That baseline becomes the first draft of the approved software list. It isn't finished, and that's fine. A short, honest list you keep updated beats a long one you don't.

Your 12 vendors go on a separate list, the service-provider inventory that CIS Safeguard 15.1 asks for. Don't mix them into this one.

Field by field

Wayne before

Wiki: AWS accounts wayne-mgmt · wayne-prod · wayne-staging · wayne-dev

laptops.xlsx (171 rows, last edited 2023) Columns: Hostname, Model, Given to

Owner column: none. Last checked: unknown.

Wayne after (extract)

The full register has all seven accounts, 185 laptop rows (including 9 spares and 4 missing), and the start of a software list. Every row has a named owner, a source and a date.

From three lists that disagree to one list with owners.

What an auditor accepts vs rejects

Auditors test an inventory in two directions. They pick something real, such as a laptop on a desk or an account in the AWS console, and ask to see it on your list. Then they pick rows from your list and ask to see the real thing.

Floor to list, then list to floor.

That third row surprises people. A reconciliation that never finds anything doesn't look clean to an auditor. It looks like nobody really checked.

Friday, 2:30 PM: Evidence #3

By Friday you have one register in place of three lists, and a one-page reconciliation note:

• 7 of 7 AWS accounts listed and owned.

• 158 laptops matched; 14 added; 31 stale AD objects queued for removal; 9 spares recorded.

• Open: 4 laptops missing, with former holders being contacted.

• Open: hack23-db-final contents unverified; closure of hackathon-2023 on hold.

• Open: the 2021 access key in old-sandbox, which Dan disabled that afternoon.

You send it to Dan. He replies at 2:30 PM: Reviewed. Agree with the open items.

That note and reply get filed next to the ownership email and the scope approval. Evidence #3 is dated and reviewed, and it includes the problems it found.

Priya isn't thrilled her account is still open. But she agrees it's better than deleting something she can't describe.

A reconciliation that found problems is better evidence than one that found nothing.

What you actually do on Monday

1. List your sources. Cloud organization, directory, MDM or endpoint tool, finance statements, any spreadsheet that already exists.

2. Pull from each one and put them side by side. Don't clean anything yet.

3. Compare and count the differences. The number doesn't need to be small. It needs to be written down.

4. Put a person's name in the owner column for every row. Use "unknown" where you have to, and treat each "unknown" as an open item.

5. Book the next comparison in your calendar. Monthly is a good start, and CIS asks for at least twice a year.

Framework mapping

Inventory shows up in every major framework.

Maturity ladder

The 20-person version really is a spreadsheet, and that's fine. An auditor cares whether it's accurate and maintained, not whether you paid for a tool.

Where Wayne sits: it moved from "Starting" to the first step of "Working" this week. It has one register and one completed comparison. The next comparison is booked but hasn't happened yet.

Cheatsheet

The takeaway

You can't protect what isn't on the list. An inventory is a list plus an owner plus proof you keep checking it. The differences you find aren't failures. They're the evidence the control works.

⚠️ This content is for educational purposes only. Wayne Industries is a fictional company. Nothing here is legal, audit, or compliance advice, validate against your own auditor and jurisdiction.

One line on one page decides what an auditor will look at: the scope.

Monday, 8:52 AM

Dan Okafor leans into your doorway holding his phone like it's good news.

"Maya wants us certified. ISO 27001. I asked a certification body for a quote, and they sent back a form." He scrolls. "First box: scope of certification. Let's just put wayne-prod. Smaller scope, smaller bill, faster audit. Gotham Mutual only cares about production anyway."

Priya Nair, walking past with a coffee, adds: "Makes sense. Prod is where the customers are."

It sounds right. But you remember last week. The bucket you locked was called wayne-staging-data, and the file inside was prod-export-2024.sql.gz: a full production database export, sitting in staging, open to the internet.

Customer data doesn't stay where the architecture diagram says it lives.

"Give me until Friday," you tell Dan. "Before we write a scope, I want to know what we actually own."

Dan's plan: Put one AWS account on the form and call it done.

What a scope actually is

An ISMS (Information Security Management System) is the whole set of people, rules, processes and controls you use to run security. It's not a tool. It's the way the company works.

The scope is the boundary of that system. It says: these teams, these locations, these systems and this information are covered. Everything else isn't.

Think of it as a fence around a yard. Your controls are the house rules inside the fence. The auditor walks the fence line and checks that the rules are followed inside it. If you only fence the front lawn, the auditor never looks at the back gate. The dog still gets out the back gate. And your certificate still says "fenced."

ISO/IEC 27001:2022 Clause 4.3 is the requirement. In plain words, it asks you to:

• Decide the boundaries and applicability of your ISMS;

• Base that decision on the issues you found in Clause 4.1 (your context), the requirements you found in Clause 4.2 (what interested parties need), and the interfaces and dependencies between your work and work done by other organizations;

• Keep the scope as documented information, meaning written down where people can find it.

It's one of the few documents the standard explicitly demands.

The unpopular truth: the scope line is the only part of your ISO certificate most customers will ever read. Gotham Mutual's vendor-risk team won't read your policies. They'll read the one sentence that says what the certificate covers, and check whether their data is inside it.

First, survey the land

You can't draw a fence around land you haven't surveyed. Wayne's documentation lists four AWS accounts: wayne-mgmt, wayne-prod, wayne-staging and wayne-dev. Documentation is what people remember. AWS Organizations is what exists.

From the management account, you run:

aws organizations list-accounts \
  --query 'Accounts[].[Name,Id,State,JoinedMethod]' \
  --output table

Sample output (illustrative). Wayne Industries is fictional.

----------------------------------------------------------
|                      ListAccounts                      |
+-----------------+---------------+---------+------------+
|  wayne-mgmt     |  104829365117 |  ACTIVE |  CREATED   |
|  wayne-prod     |  238571940652 |  ACTIVE |  CREATED   |
|  wayne-staging  |  349162058734 |  ACTIVE |  CREATED   |
|  wayne-dev      |  457203816495 |  ACTIVE |  CREATED   |
|  hackathon-2023 |  562918374026 |  ACTIVE |  CREATED   |
|  marketing-test |  671034928157 |  ACTIVE |  CREATED   |
|  old-sandbox    |  780145263398 |  ACTIVE |  CREATED   |
+-----------------+---------------+---------+------------+

Seven accounts. Three that nobody wrote down.

A practical note: AWS retired the old Status field on Organizations account APIs on September 9, 2026. Use State, as above. If you have an older script filtering on Status, it may now quietly return nothing, which is the worst kind of inventory result: it looks clean.

To find out who owns each mystery account, check the root email address on each one:

aws organizations describe-account --account-id 562918374026 \
  --query 'Account.[Name,Email,JoinedTimestamp]' --output text

Sample output (illustrative). Wayne Industries is fictional.

hackathon-2023  priya.nair@wayne-industries.example  2023-06-09T14:22:51.402000+00:00

You repeat that for the other two and walk the list around the office.

• hackathon-2023: Priya's. "I thought that got shut down after the hackathon."

• old-sandbox: Dan's. "That's… from a while ago. I'll look."

• marketing-test: created for the outside web agency that built the marketing site. Nobody at Wayne logs into it.

Four accounts on paper. Seven in AWS.

The unpopular truth: most scope mistakes aren't choices. They're things nobody knew existed. A scope written from memory is a scope with holes.

The three inputs Clause 4.3 wants

Before you write a word of scope, collect the three inputs. Here's Wayne's short version.

1. Issues (Clause 4.1). What's going on inside and around Wayne that affects security?

• Cloud-only SaaS company in Vancouver, British Columbia. No data centre of its own.

• One security person.

• Customer data has already ended up in the wrong account once.

2. Interested parties and their requirements (Clause 4.2). Who cares, and what do they need?

• Gotham Mutual: a $1.8M deal, a vendor questionnaire, a request for assurance.

• Existing customers: their personal information protected.

• PIPEDA, Canada's federal private-sector privacy law: Wayne stays accountable for personal information it holds.

• Maya and the board: a certificate that actually helps sell.

3. Interfaces and dependencies (Clause 4.3 c). Where does Wayne's work touch someone else's?

• AWS runs the infrastructure; Wayne runs the configuration and the data.

• The outside web agency works inside marketing-test.

• Twelve vendors, none security-reviewed yet.

Three inputs go in, one scope statement comes out.

Why scope sets your audit cost (and why "just prod" doesn't save much)

Dan's instinct isn't wrong: scope does drive audit cost. But how it drives cost is the part most people miss.

Certification bodies calculate ISO 27001 audit time using ISO/IEC 27006-1:2024, Annex C. The starting point is the number of persons doing work under the organization's control within the scope, and the 2024 version makes clear this includes people who aren't employees, such as contractors. The certification body then adjusts that number up or down for complexity: how many systems, how much outsourcing, how much is already in place.

So think about what cutting wayne-staging from scope really does at Wayne. The same engineers deploy to prod and staging. The same people, the same laptops, the same GitLab, the same identity system. Removing the staging account removes almost none of the people. What it does add is a new boundary you now have to explain: how production data is kept out of an account you have declared out of scope.

Where scope genuinely saves money is when a whole part of the business, with its own people and systems, has nothing to do with the service you're certifying.

And the audit fee is only part of the bill. Every system inside the fence needs controls that operate and evidence that proves it. That's the bigger cost, and it's paid in your team's time.

Every certification body quotes differently. Ask yours how they count people and what adjusts the number.

The unpopular truth: a narrow scope mostly shrinks what you're forced to look at, not what you pay. The risk outside the fence doesn't get smaller because the auditor stopped looking.

Audit time starts with people in scope, then adjusts for complexity.

Field by field

Wayne before

Scope: Wayne production platform (wayne-prod AWS account). Exclusions: — Approved by: — Date: —

Four problems in four lines. No people, no data, no interfaces, no reason for leaving the other six accounts out, and nobody signed it.

Wayne after

Scope statement: The information security management system of Wayne Industries covering the development, operation and support of the Wayne cloud SaaS platform, and the customer information processed by it.

Organizational units: Engineering, operations, security and customer support, plus leadership in its governance role. Contractors with access to in-scope systems are included.

Locations: Vancouver, BC office, and staff working remotely.

Services and processes: Software development, deployment, platform operations, customer support and access management for the SaaS platform.

Technology: All seven AWS accounts in the Wayne AWS Organization (wayne-mgmt, wayne-prod, wayne-staging, wayne-dev, hackathon-2023, marketing-test, old-sandbox); Active Directory; self-hosted GitLab; company-managed laptops.

Information: Customer personal information and account data, source code, credentials and secrets, backups and logs.

Interfaces and dependencies: AWS (infrastructure; Wayne manages configuration and data); outside web agency (works in marketing-test); twelve vendors (to be reviewed).

Exclusions: None at this stage.

Accounts pending closure: hackathon-2023 (owner: Priya Nair) and old-sandbox (owner: Dan Okafor) stay in scope until closure is complete.

Owner: Head of Security. Approved by: Maya Lindqvist, CEO. Date: Friday. Next review: in 12 months, or sooner on a significant change.

Same form, two answers. Only one survives the first audit question.

Notice what happened to the three mystery accounts. The instinct is to leave them out because they're "not real." That's backwards. An account nobody watches is exactly where a leak starts. So they go in, with named owners, until they're closed. Once an AWS account is closed, it doesn't vanish on the spot; it sits in a closed state for a reinstatement window first. The scope says "until closure is complete" for that reason.

Also notice "Exclusions: None." A first honest scope is often wider than you'd like. That's fine. You can narrow it later, with a reason you can defend.

What an auditor accepts vs rejects

The auditor's favourite question: "And what's in that account?"

Interfaces: where your fence touches someone else's

The word "interface" scares people. It just means: a place where another organization does work that affects your security.

For Wayne, the clearest one is the web agency. They have access to marketing-test. Wayne can't control how the agency runs its own office, but Wayne can control what the agency is allowed to reach, and what's written in the agreement.

So the scope doesn't pretend the agency is inside Wayne. It says the agency is an interface, and that Wayne manages the relationship. You can't outsource accountability. PIPEDA says the same thing: an organization stays responsible for personal information it transfers to a third party for processing (Schedule 1, Principle 4.1.3).

AWS is the same story at bigger scale. AWS secures the infrastructure. Wayne secures what it builds on top: configurations, identities, data. The public bucket last week was Wayne's side of that line, not Amazon's.

"We just built the website." Then why do you have keys to an AWS account?

Friday, 3:15 PM: Evidence #2

You send Maya and Dan the scope document with a one-line summary: all seven accounts in, two being closed, nothing excluded yet.

Dan reads it twice. "Wider than I wanted."

"It's the one that's true," you say. "The narrow one would have lasted until the auditor asked about staging."

Maya replies at 3:15 PM: Approved.

That reply, with the document attached, gets filed next to last week's ownership email. Evidence #2: dated, named, approved.

Then you send Gotham Mutual the scope statement, the one-sentence version. It's not a certificate. But it's an honest answer to "what would your certificate cover?", and that's a better answer than a promise.

One document, one approval, one date.

What you actually do on Monday

1. Pull your real inventory. Cloud accounts, subscriptions, projects, tenants. From the platform, not from the wiki.

2. Put a name next to every account you didn't know about. If nobody claims it, that's your first risk.

3. Write your three inputs on one page: issues, interested parties and their requirements, interfaces.

4. Grab a published scope template and fill in every field, including "exclusions and justification."

5. Get it approved by someone with authority, in writing, with a date. Put a review date on it.

Framework mapping

Every framework asks the same first question: what exactly are we talking about?

Maturity ladder

Honestly, the 20-person version is a spreadsheet and an email. That's fine, as long as the spreadsheet is true.

Where Wayne sits: somewhere between the first two columns. The scope document now looks like the 200-person version. The inventory behind it is still one command run by hand.

Cheatsheet

Scoping your ISMS on one page.

The takeaway

The scope is a fence, and the auditor only walks the fence you draw. Draw it from what exists, not from what you remember. A narrow scope rarely saves much. It mostly hides what you'd rather not find. Get it signed, dated and reviewed, and it becomes evidence.

⚠️ This content is for educational purposes only. Wayne Industries is a fictional company. Nothing here is legal, audit, or compliance advice, validate against your own auditor and jurisdiction.

Illustrations in this post were created with AI assistance. Wayne Industries is fictional.

@18xBan · GRC Series · Chapter 01

⚠️ This content is for educational purposes only. Wayne Industries is a fictional company. Nothing here is legal, audit, or compliance advice, validate against your own auditor and jurisdiction.

Monday, 9:14 AM

You are the only security person at Wayne Industries, a cloud SaaS company in Vancouver, British Columbia. There are about 240 accounts in Active Directory, and exactly one of them belongs to someone whose job title contains the word "security." That's you.

Dan, the CTO, forwards you an email. The subject line reads FW: FW: Security requirements : Gotham Mutual. His note on top is one line long:

"Big deal. They need this by Friday. Can you do the GRC thing?"

Attached are a 214-question vendor security questionnaire, a request for "Your most recent SOC 2 Type II Report," and a sentence asking Wayne Industries to confirm it has "a documented risk management program approved by senior leadership."

Here's where Wayne Industries actually stands:

• No SOC 2 report.

• The "risk management program" is an email thread from 2022 titled stuff that worries me.

• Senior leadership has never approved anything security-related, because nobody ever asked them to.

For most people, "the GRC thing" is where their understanding of GRC starts and stops: a pile of paperwork that gets filled out so a deal can close. By the end of this post you'll see why that picture is wrong, and why believing it gets expensive.

Three letters that get said as one word

G, R, C. Governance, Risk, Compliance. People say it as a single word, and that habit causes half the confusion. The three parts do different jobs:

• Governance is who gets to decide, what they decide, and how anyone can tell a decision was made.

• Risk is working out what could hurt you, how badly, and what you'll do about it with the budget you really have.

• Compliance is proving to someone outside your company that you do what you say you do.

If that still feels abstract, picture a restaurant kitchen.

• Governance is the head chef. The chef sets the menu, decides who's allowed near the deep fryer, and decides what happens when a plate goes out wrong.

• Risk is knowing the fryer can start a grease fire. You decide that justifies a suppression system this month, while the wobbly shelf can wait until next month.

• Compliance is the health inspector who walks in with a clipboard. You hand over the fridge temperature log you've filled in twice a day since March.

The inspector doesn't care that you feel the fridge is cold. They want the log. That idea comes back in nearly every post in this series.

Pin Wayne's mess to the wall

Before we define anything else, let's look at the evidence. This is what a first walk through Wayne turns up:

Here's what three of those exhibits look like when you ask the systems directly. You can run the same commands against your own environment.

Exhibit 1: the accounts nobody wrote down

$ aws organizations list-accounts --query 'Accounts[].[Name,Email,Status]' --output table
---------------------------------------------------------------------
|                           ListAccounts                            |
+------------------+---------------------------------------+--------+
|  wayne-mgmt      |  aws-root@wayne-industries.example    | ACTIVE |
|  wayne-prod      |  aws-prod@wayne-industries.example    | ACTIVE |
|  wayne-staging   |  aws-staging@wayne-industries.example | ACTIVE |
|  wayne-dev       |  aws-dev@wayne-industries.example     | ACTIVE |
|  hackathon-2023  |  priya.nair@wayne-industries.example  | ACTIVE |
|  marketing-test  |  web-agency@contractor.example        | ACTIVE |
|  old-sandbox     |  dan.okafor+aws@wayne-industries.example | ACTIVE |
+------------------+---------------------------------------+--------+
# The last three aren't in any inventory. One is registered to an outside agency.

Sample output (illustrative). Wayne Industries is fictional.

Exhibit 2: who holds the keys to the domain

PS> Get-ADGroupMember -Identity "Domain Admins" | Select-Object Name, SamAccountName

Name            SamAccountName
----            --------------
Administrator   Administrator
Dan Okafor      adm.dan
Deploy Service  svc-deploy
# Administrator is the built-in account. Who approved adm.dan and svc-deploy?
# No ticket, no email, no answer.

Sample output (illustrative). Wayne Industries is fictional.

Exhibit 4: the bucket with the door open

$ aws s3api get-public-access-block --bucket wayne-staging-data
{
    "PublicAccessBlockConfiguration": {
        "BlockPublicAcls": false,
        "IgnorePublicAcls": false,
        "BlockPublicPolicy": false,
        "RestrictPublicBuckets": false
    }
}
# Every public-access guard is switched off.

Sample output (illustrative). Wayne Industries is fictional.

Here's a game. Label each row G, R, or C before you read on.

Done? Every row is all three. Take the public S3 bucket:

• As a risk: customer data could leak, and it probably will. Internet scanners look for public buckets all day.

• As a governance problem: nobody decided who is allowed to make a bucket public, so in practice anyone can.

• As a compliance problem: Gotham Mutual's question 47 asks whether customer data is access-restricted. If Wayne answers "yes," it's lying. If Wayne answers "no," it loses the deal.

The unpopular truth: Most teams file a public bucket under "security problem" and fix it by clicking Block public access. That's the right click. But if you stop there, a developer creates a new public bucket next sprint. The thing that was really broken is still broken: nobody decided who's allowed to do that.

Security fixes the bucket. GRC fixes the reason the bucket happened.

Honestly, that sentence is the whole post. Everything after it is detail.

Governance: The part everyone skips because it sounds like meetings

Governance is about decision rights. Try this test at Wayne. Ask three people who approves a production deploy:

• The CTO says the team leads do.

• A team lead says the CTO does.

• A developer asks, "...approves?"

Here's the setting behind the shrug, pulled from GitLab's API:

$ curl -s --header "PRIVATE-TOKEN: <your-token>" \
  "https://gitlab.wayne-industries.example/api/v4/projects/42/protected_branches"
[
  {
    "name": "main",
    "push_access_levels":  [{ "access_level": 30, "access_level_description": "Developers + Maintainers" }],
    "merge_access_levels": [{ "access_level": 30, "access_level_description": "Developers + Maintainers" }],
    "allow_force_push": false
  }
]
# Anyone at Developer level can merge straight to main. Nobody chose this.

Sample output (illustrative). Wayne Industries is fictional.

This is a governance failure that shows up as a technical setting, and most governance failures look like that. Nobody made a bad decision here. Nobody made a decision at all, so the default settings made it for them.

Governance comes down to four questions:

1. Who owns security, and who do they report to?

2. How much risk are we willing to carry? This is risk appetite.

3. Who is allowed to accept a risk instead of fixing it?

4. How does leadership find out when something goes wrong?

At Wayne, the honest answer to all four is "the CTO, probably, by email." That isn't governance. It's one person.

The unpopular truth: Policies aren't governance. Wayne has 40 of them. They look like governance, but if no one owns them, no one reviews them, and nothing happens when they're broken, they're decoration.

Risk: Choosing what to worry about with the money you have

Wayne has one security person and no security budget line. You can't fix ten things this week. Risk management is the discipline of choosing which ones come first.

The most common beginner mistake is treating scanner output as a risk list. A scanner tells you the bucket is public. It can't tell you whether the bucket holds marketing PDFs or a copy of your customer database. That second fact changes everything.

So you check the bucket at Wayne:

$ aws s3 ls s3://wayne-staging-data/ --human-readable
2023-09-03 10:01:55  220.5 KiB demo-screens.zip
2024-02-11 16:22:07    1.2 GiB prod-export-2024.sql.gz
2024-02-11 16:25:40   14.3 KiB readme.txt
# A production database export, in a staging bucket, open to the internet.

Sample output (illustrative). Wayne Industries is fictional.

Someone copied a production database export into staging "for testing." The bucket just moved from "tidy this up sometime" to "stop what you're doing."

Now look at the three shadow AWS accounts. What's in them? Nobody knows, which means their risk is also unknown. You can't assess something you can't see.

Next, the email thread:

A concern with no owner, no rating, no deadline and no decision is a worry, not a risk. A risk register exists to turn worries into decisions that someone signs their name to.

Compliance: Proving it to someone who doesn't trust you yet

Back to Gotham Mutual. They've never met Wayne and they can't log into Wayne's AWS console. So they ask for proof: answers, reports, evidence.

Compliance faces outward, and it runs on evidence. Some of the demands you choose to take on, and some are imposed on you:

• Chosen, usually because customers ask: SOC 2 and ISO 27001.

• Imposed by law or contract: PIPEDA for Canadian personal information, GDPR if EU residents are involved, and PCI DSS once card data appears.

Two uncomfortable truths belong in the first post of any GRC series.

1. You can be compliant and still get breached. Auditors test samples. Attackers don't limit themselves to a sample.

2. You can be secure and still fail an audit, because you can't prove it. Wayne's nightly backups might be perfectly good. Without a single dated restore test, an auditor has to treat them as untested. "We do it" is a claim. A dated, reviewed record is evidence.

How the three pieces fit together

This is the loop that ties the three parts together:

Governance sets direction and risk appetite → Risk ranks what matters against that appetite → Controls get built → Compliance tests and proves those controls → Findings go back to governance → the loop repeats.

Wayne has broken every link in the loop:

• Governance never set an appetite, so risk has nothing to measure against.

• Without that, controls get built at random.

• With random controls, compliance has nothing coherent to prove.

• Any findings that do turn up have nowhere to go.

The only reason anyone noticed is that a customer asked. That's normal. Most companies start doing GRC because a customer, a regulator, or an incident forced them to, not because someone at an offsite thought it sounded fun.

What GRC is not

Wayne's first hour: What you actually do on Monday

Don't open the 214 questions yet. Answer three questions of your own first.

1. Who decides? Book 30 minutes with Maya, the CEO, and Dan, the CTO, and leave with one sentence: "Security is owned by Head of Security, who reports to CTO, and CTO is the person who accepts risk." Send it as an email and get a "confirmed" reply. That dated email is Wayne's first piece of governance evidence. It's tiny, it's real, and it counts.

2. What could hurt us most? Lock the public bucket now, because that's an emergency, not a project. Then replace the email thread with a 10-row list that gives every item an owner, a rough rating, and a next step. A spreadsheet is fine for this.

3. Who is asking us to prove what? List every external obligation:

• Gotham Mutual, with its questionnaire and SOC 2 request.

• PIPEDA, for the Canadian customer data.

• Anything already in existing customer contracts.

That list becomes your compliance scope.

After that, reply to the CTO with the honest version: "We can answer the questionnaire truthfully by Friday. Nobody can produce a SOC 2 Type II by Friday, because it needs an observation period measured in months. Here's what I suggest we tell Gotham Mutual instead."

The unpopular truth: The worst thing you can do on Friday is answer "yes" to things that aren't true. Questionnaire answers have a way of ending up attached to contracts. A "yes" that turns out to be false is no longer just a sales problem. It becomes a legal one.

Framework mapping

The GDPR row makes the same point as the kitchen analogy: regulators expect you to demonstrate compliance, not just claim it.

Maturity ladder: The same GRC at three company sizes

Where's Wayne? It's a 240-person company running a GRC program built for 20 people, minus the 20-person version's saving grace: at 20 people, everyone knows who owns what. Closing that gap is what this series is for.

Cheatsheet

The takeaway

GRC isn't the paperwork that shows up after security work. It's the system that decides which security work happens, who owns it, and how you prove it happened. Wayne doesn't lack tools. It lacks decisions. By Friday it will have exactly one, written down, dated and confirmed, and that's a real start.

// @18xBan