0.4 The Assessor's Templates

Introduction

An assessment produces two kinds of output. The report is what the organization reads. Behind it sits a set of working documents: what was planned, what was asked for, what arrived, what was tested and what was found.

Those working documents are what make the report defensible. When a control owner disputes a finding, or a second assessor picks up the work a year later, the question is always the same: show me how you got there.

This course gives you seven templates for those working documents, as free downloads you can use in your own work. Each is a CSV file with a guidance row that says what belongs in each column, and each comes with a completed example worked on the leaver control from lesson 0.1, so you can see every column filled in with real entries from the evidence pack.

The templates follow the order an assessment runs in. The plan and the test matrix are written before any evidence arrives. The evidence register and the sampling worksheet fill up while you test.

The last three exist only for statements that come out other than satisfied: a finding records the failure, the remediation tracker records what will change, and the retest record shows whether the change worked. This lesson walks through each one using the completed examples, then describes how to adapt them.

Every assessment answers the same questions, whatever the control and whatever the framework. What were you asked to assess, and against what? Which statements did you decide, and on what evidence? What did the evidence show? What failed, and what is being done about it? A template is a fixed place to write each answer, so that none is skipped and every assessment can be read the same way.

The templates are deliberately plain. They are CSV files, which open in any spreadsheet application and can be read by any script, and their columns are the minimum an assessment needs. Many organizations run assessments in a governance platform with its own forms; the columns here map onto those forms, and knowing what each column is for makes it easier to fill in a platform's version well.

Two documents you have already seen in this module are not templates. The workpaper is how this course shows a single determination being made: the test matrix row, executed, with its result. And the determination statement itself lives in the test matrix's "Determine if" column. Everything else an assessment records sits in one of the seven files.

Templates also make the work checkable by someone else. A reviewer reading a completed set can trace any statement in the report back through the finding, the workpaper and the register to the files it rests on, without having to ask the assessor where anything came from. That trace is the test every assessment in this course is held to.

The test matrix's columns follow the shape NIST SP 800-53A gives an assessment procedure: an objective decided by applying methods to assessment objects, which NIST groups as specifications, mechanisms, activities and individuals. Using that shape is not a commitment to NIST as a framework. It is a way of making sure each row says what will be examined and how, whatever criteria the row is measured against.

The plan sets the boundaries of everything that follows. It names what is assessed and what is not, the criteria, the period, the methods, and who does what. It is agreed with whoever commissioned the assessment before any testing starts, because every later argument about a finding tends to turn into an argument about scope.

The period is the field that matters most. A determination says nothing about anything outside its period: a leaver who left in June is outside this assessment, even if their account is still enabled. Writing the period down before testing is what lets you say so plainly when somebody raises a June leaver in the closing meeting.

The out-of-scope field is just as useful. Listing what is excluded, and why, stops a reader assuming the assessment covered it. A report that says nothing about physical access because physical access was never in scope reads very differently from one that says nothing because nobody looked.

The roles field names the people the assessment depends on: the control owner, who answers for the control; whoever supplies each kind of evidence; and whoever validates findings before the report goes out. Naming them in the plan means the evidence requests go to the right people the first time, and a control owner cannot later say they never saw a finding.

Depth and coverage are recorded here as well. Focused depth with comprehensive coverage of leavers means the whole population is tested, at a level of detail that goes beyond reading the policy. Recording that choice up front lets a reader judge how much weight a satisfied determination can bear: satisfied on a basic, sampled assessment supports far less than satisfied on a comprehensive one.

Keep the plan short enough to be read. A plan that runs to many pages is usually a test matrix in disguise, and the commissioner who agrees it has not really read it.

The test matrix is the core of the plan. Each row is one determination statement, with the criterion it comes from, the method, the population, and the evidence needed to decide it. Writing the rows before evidence arrives is what keeps the assessment honest: the acceptance criterion is fixed while you still have no idea which way the answer will go.

Read the row from top to bottom and it reads as a test you could hand to someone else. The criterion is quoted from the standard and the source names the document, version and clause.

The "Determine if" column turns the clause into a statement the evidence can settle. The acceptance column fixes what counts as satisfied: every account within one business day, with no tolerance for one or two late.

The last column, evidence requested, becomes the evidence request. Naming the records precisely, the HR leaver export and the directory disable times, is what stops the organization sending a policy and a screenshot instead. Lesson 0.3 described what arrives when the request is vague.

One clause often needs more than one row. Clause 1 of the Access Control Standard has two requirements, the directory account and the non-single-sign-on applications, so it takes two rows. Lesson 0.1's practice decided the second one. A matrix with one row per clause, where the clauses hold several requirements, hides the requirements that were never tested.

The method and objects columns record how each statement will be decided. Examine, interview and test are the three methods lesson 0.2 introduced; the objects are the things the method is applied to, here the HR export and the directory disable times.

A row that names interview as the only method for a statement about what the system did is a warning sign before any evidence arrives, because a person's account of a system is weaker evidence than the system's own records.

The register lists every item of evidence as it arrives. Its columns record more than the file name: who supplied it, when, what period and population it covers, and three judgments about it, relevance, reliability and completeness. Those three judgments are made once, when the item arrives, and then cited by every workpaper that uses it.

The notes column carries the judgments that change how an item is used. E-02 is a system export, so it is reliable as to the disable times, but it was filtered to leavers by the IT team, whose control is being assessed. The note says to check it against E-01, the HR export, which comes from a function independent of IT.

E-03, the tickets, is recorded as supporting evidence only, because a ticket's closure time is when a person closed it, which may be well after or well before the account was disabled. E-04, the sign-ins after the leave date, decides nothing about the statement itself; it is registered because the finding's consequence rests on it.

Keep a row for evidence that was requested and never supplied as well. A gap in the register, with the date of the request and the date it was chased, is the record that supports a cannot-determine outcome later. Without it, a missing item simply looks as though nobody asked.

The supplied-by column matters more than it looks. Evidence that reached you through the control owner has passed through the hands of the person with the most interest in the result.

That does not make it unreliable, but it is the reason the register records it, and the reason the plan tries to source the key records from someone independent, such as HR for leavers or a read-only account for the directory.

The register also holds the hash of each file, as lesson 0.3 described, and the date it was received. If a file is replaced by a corrected version, both rows stay, with a note on the second explaining what changed and why. Deleting the first row would remove the record of what you originally relied on.

The register is also where evidence quality is argued. A reviewer who disagrees with a determination will usually start by asking about an item in the register: was this export complete, was that one filtered, who produced the other. Recording those judgments when the item arrives means the answer is already written down.

When a population is too large to test in full, you test a sample and say what the sample supports. The worksheet records how the population was defined, how you know it was complete, how items were selected and why that number is enough. The leaver control needs none of that judgment, because fourteen leavers can be tested in full, but the worksheet is still filled in.

Filling it in for a population tested in full is not busywork. The population size and the completeness check are the two fields a reviewer looks at first: fourteen leavers, and a check that the count matches what HR reported for the quarter. If the HR export had silently dropped three leavers, testing all of the remaining eleven would still be a test of an incomplete population.

The exceptions column lists the items that failed: a.dawson4@ne.com (4 business days), g.ainsworth2@ne.com (9 business days). Those two names carry through to the finding. When you sample a larger population, the same column is where you look for a pattern among the failures, such as the same approver, the same week or the same system, which is often the first evidence of a cause.

Module 5 covers sampling properly, including how to size a sample and how to extend a conclusion from a sample to a population. For now, the habit to form is that every population gets a row, sampled or not, so the size and completeness check are always on record.

For a sampled population, the seed or start column records how the selection was made repeatable: the random seed, or the starting point and interval of a systematic sample. Another assessor given the same population and the same seed should select the same items. A sample nobody can reproduce is a sample nobody can check, and it invites the suspicion that the items were chosen because they would pass.

Even a sample of one leaves a trace here, so a reader can see it was a choice.

The same discipline applies to the completeness check. Record the independent total you compared against, with its source and date, beside the population size. A completeness check written as "confirmed" tells a reviewer nothing they can repeat; one written as "14, matched to the HR export received 1 October" can be checked in a minute.

A finding is written only for a determination of other than satisfied. It sets out four things in a fixed order: the criterion, what was required; the condition, what the evidence shows; the consequence, what can happen because of the gap; and the cause, why it happened, where the evidence supports one.

The condition carries the counts: two of fourteen, with the number of business days for each. A condition that says "some leaver accounts were disabled late" leaves the reader to guess whether that means two or twelve, and the severity rating cannot be checked against it.

The cause is recorded as not established. That is a legitimate entry, and a common one. The evidence shows when each account was disabled, but nothing in the pack shows why two were late, and guessing at a cause in a finding invites the control owner to dispute the guess and, with it, the finding. Module 9 covers how to establish a cause when the evidence allows it.

The last two fields record validation: the finding was put to the Head of IT Operations, who owns the control, before it went into the report. Validation is how factual errors are caught while they are still cheap to fix. The owner may dispute the severity or explain the cause, but if they can show the facts are wrong, the finding should change before anyone else reads it.

The severity rationale explains the rating in one sentence, and it is the field a disputed finding most often turns on. Medium here rests on two things the evidence shows: two exceptions in one quarter, and sign-ins on both late accounts after the leave date.

Writing the reasons down means a reader can disagree with the rating while still accepting the facts, which is a much easier conversation than a dispute about both at once.

A finding written to this structure is easy to validate, because each part can be checked on its own. The owner can agree with the condition and dispute the consequence, or accept both and question the severity. Disagreements become specific, and specific disagreements are usually resolved quickly.

The last two templates follow a finding to its close. The remediation tracker records what the control owner will change, who owns the change, when it is due, and what will reduce the risk in the meantime. The retest record records the test that decides whether the change worked.

The column that matters most in the tracker is the last one: the closure evidence required. It is agreed when the action is agreed, so nobody later argues about what proves the fix. Here it is the next quarter's leavers with their directory disable times, which is the same evidence the original test used, taken from a later period.

The retest record repeats the original determination statement unchanged. That is the point of it: the retest asks the same question of a new period. A retest that asks a softer question, such as whether the new automation exists, can close a finding while the control still fails.

Retesting on a later period also matters. A fix made on 15 December cannot be tested on Q3 leavers, so the retest waits for a quarter with enough leavers to show whether the change worked.

The recurrence check is the last field. A control that was fixed once can drift back, especially when the fix depended on a person rather than a system, so the retest record sets a date to look again.

The compensating control column is filled in only where something genuinely reduces the risk while the fix is built. A daily report of HR leavers whose accounts are still enabled does that: it cannot stop an account being disabled late, but it shortens how long a late one goes unnoticed.

An entry that only restates the policy, or a promise to be more careful, reduces nothing and should be left blank.

Retest dates are agreed with the owner, not imposed. A date that leaves no room for the fix to run for a full period produces a retest that cannot decide anything.

The downloads below are the seven templates, each blank with its guidance row, and each completed for the leaver control. Open them alongside this lesson: every entry shown above comes from the completed examples, so you can compare the full rows with the excerpts here.

Adapt them freely. Add columns your organization needs, such as a framework mapping, a control ID from a governance platform or a business unit, and rename columns to match your organization's vocabulary. Keep the columns that carry the assessment's logic: the determination statement, the acceptance criterion, the population and its completeness check, the evidence reference and, on a finding, the condition with its counts.

Each file starts with a single comment line naming the course. Spreadsheet applications show it as the first row, and a script reading the file should skip it. Remove it in your working copies if you prefer.

Keep a completed set together, one folder per assessment, with the evidence it cites. The files work as a set: a finding cites a workpaper reference, the workpaper cites register IDs, and the register cites the files.

If one file is renamed or moved, the trace breaks. Version the set when it changes after review, rather than editing in place, so the record shows what the report was based on when it was issued.

Every lesson and exercise from Module 1 onward uses these templates. The exercises ask you to fill them in on the evidence pack, and the course exam is marked in part on the completed set.

When you adapt them for a team, agree two things before the first assessment: the identifier scheme for statements, register items and findings, and where completed sets are kept. Both are hard to change later, because every completed set cites them. A statement called AC-01.1 this year and AC-1a next year breaks the link that lets a retest find the finding it closes.

The next lesson puts all of this together on one control, emergency access, from the test matrix row to the determination.