0.6 Lab: First Read of the Evidence Pack

Introduction

A first read of an engagement's evidence is a discipline of its own, and most architects skip it. The temptation on a first week is to start fixing what looks broken, and the cost is designing against a picture of the organization that nobody else shares.

A first read builds that shared picture: what the evidence says, where it contradicts itself, and what you still need to ask, agreed with the person you report to before any design is proposed.

This lab is Module 0's: your first assignment as Northgate Group's security architect. It produces the first deliverable in your portfolio, a short note to the CISO that every later module builds on.

The four steps in the figure are the method, and the note is the product. It proposes nothing, which is harder than it sounds: half the skill of a first read is noticing a problem and writing it down as a question instead of a fix.

An inject is the event that starts the work, and reading it precisely is the first skill a lab tests. Most of what goes wrong in a first deliverable starts with answering a different question from the one asked. Here it's a message from the person you report to, which makes it both a task and a statement of what she cares about.

Your first morning at Northgate starts with a message from Rachel Okafor, the group CISO. She wants it answered before your first one-to-one, at the end of the week:

Read what she asked for, and what she didn't. She wants the facts you'd rely on, the contradictions and the questions, and she wants them before any design. She also says why: to know that the two of you are looking at the same group. The note she gets back tells her whether that is true.

The evidence is the pack: thirteen files, from the group overview to the tenant exports. Lesson 0.5 lists them with what each holds, and the order of reading in the task below is the one it suggests.

The steps are the ones lessons 0.1 to 0.5 practiced on single files, applied to the whole pack at once. The order matters, because the early files give you the context to read the later ones.

The task runs in six steps. Keep a fact log from the first file you open; it's the raw material for every section of the note, and the habit carries into every later lab.

A few cautions from engagements like this one. Don't trust a document's summary over the data it summarizes: where the overview, an inventory and an export disagree, compare their dates and what each was written to record before choosing.

Don't settle a contradiction by deciding who is more senior. And don't let a question become a recommendation by the way you phrase it: "Should we remove the provider's account?" is a proposal; "What does the former provider still run for Präzision?" is a question.

Choosing which requirements a first note must touch is itself a judgment. These were chosen because the evidence speaks to each of them from more than one direction.

Every deliverable in the course traces to requirement IDs, and this one starts the habit. The note must touch each of these, by ID, in its facts, its contradictions or its questions:

1. BR-02, BR-03 and CON-05: the integration deadline, the US assessment and the constraint on Systems' tenant, because the order of work depends on them.
2. SR-03 and SR-05: standing privilege and the former provider, because the exports and the audit speak to both.
3. SR-12 and CON-07: one SOC view, against a contract that covers one company.
4. BR-04, SR-07 and SR-08: the drawings, which the risk appetite, the interviews and a draft policy all address.
5. CON-01: the budget every later design is priced against.

In practice that means one of three things for each ID: what the evidence says about it today, where the evidence disagrees with it, or what you'd need to know before designing for it.

A note has a shape so that its reader knows where to look. Rachel Okafor will probably read the questions first, because that's where she can help; the facts and contradictions tell her how far your understanding has got. A note without that shape makes her search for the part she needs.

The note has five sections, kept short enough to read in one sitting:

1. The group in a paragraph: what Northgate Group is, what its board wants and what it won't accept, in your words.
2. Facts I will rely on: ten to fifteen facts later designs will depend on, each cited to its file, object and date.
3. Contradictions: at least five places where two sources disagree, each with both citations and what would settle it.
4. Questions and owners: the questions you need answered before designing, each with the accountable owner from the RACI.
5. What I will read next: the files you'll go back to first when Module 1 starts, and why.

Write it for Rachel Okafor, who knows the group better than you do and wants to know what you've understood. Lead each section with what matters most.

Acceptance criteria are how you check your own work before someone else does, and every lab in the course ends with them. Mark each one Met, Partly or Not met as the CISO would: each is either visibly met in the note or it isn't. Marking a criterion opens how the model note meets it and where notes most often fail it.

When every criterion is marked, the model note opens, with the fact log it was written from. Compare it with yours section by section, and note where you chose different facts or contradictions and why.

When it passes, it goes into your portfolio as the first entry. Module 1's lab asks for a first view of the group's architecture and its three major risks, and it starts from the facts, contradictions and questions in this note.

Practice

The lab is the practice for this module. Complete the note above and accept it against the criteria before starting Module 1.