0.5 A First Determination

Introduction

The first four lessons took the parts of an assessment one at a time: what a determination is, what its reasons are, what the evidence pack holds, and which templates record the work. This lesson puts them together on a single control, from the criterion to a draft finding, so you can see each step depend on the one before it.

The control is emergency access. Every Microsoft Entra ID tenant should have accounts that can sign in and administer the tenant when everything else fails: when Conditional Access is misconfigured, when the identity provider for administrators is down, or when every administrator is locked out.

Those accounts are rarely used, which is exactly why they need testing. An account nobody signs in to for a year can fail silently, through a credential nobody can find, a lost hardware key or a policy change that blocks it, and the failure is discovered at the worst possible moment.

Northgate's standard requires a sign-in test of each emergency access account every quarter. The question for the assessment is whether that happened in Q3, and whether the evidence shows it. The steps follow the order of the templates: the criterion, the test matrix row, the population, the evidence, the determination, and a draft finding.

Every determination starts with the words of the requirement. Here they come from the Access Control Standard, and two clauses matter: clause 4, which sets the test, and clause 3, which says how many emergency access accounts there should be.

Clause 4 holds two requirements joined by "and": a sign-in test once a quarter, and a record of the test. An assessor could split them into two statements. Here they stay together, because the evidence that decides one decides the other: the organization's own test record. A test nobody recorded fails the second requirement whatever the sign-in logs show, so a single statement covering both is enough.

The words also fix what does not count.

The clause asks for a sign-in, so a check that the account exists or that its password was rotated is not a test in this sense. It asks for a quarterly test, so a test in March says nothing about the quarter from July to September. And it asks for each account, so testing one of two is a failure for the other.

Clause 3 matters for a different reason. It says there are two emergency access accounts, both holding Global Administrator permanently. That sentence will become important when the population is counted, because a criteria document is a statement of what should exist. It is not evidence of what does.

Notice what the clause does not say. It does not say how the test is performed, who performs it, or where the record is kept. Those gaps are normal in a standard, and the assessment does not fill them with assumptions. Any record of a sign-in test, dated in the quarter and kept by the organization, would meet the clause.

It is worth deciding at this point, too, what the period means for a quarterly requirement. The assessment period is exactly one quarter, 1 July to 30 September, so a test anywhere inside it meets "once a quarter" for Q3. Where an assessment period spans several quarters, the statement would need one test in each, and the matrix row would say so.

The clause also says the test must be recorded, which turns a technical check into a documentary one. Even a perfect sign-in, if nobody wrote it down, leaves the requirement unmet.

That has a practical consequence for the request. The evidence asked for is the organization's record of the test, not the sign-in log alone. Sign-in logs can corroborate a recorded test by showing a sign-in at the time the record gives, and they can expose a recorded test that never happened. They cannot stand in for the record the clause requires, however clear they are.

With the clause read, the test matrix row can be written. It is written before any evidence is opened, so that the acceptance criterion is fixed while the answer is still unknown.

The population entry deserves attention. It says every emergency access account in the tenant, taken from the directory. It does not say two, even though the standard does, because the population of an assessment comes from records of what exists, and the standard records what was intended. If the two differ, that difference is itself something the assessment has to deal with.

The acceptance entry is strict: a recorded sign-in test, dated within the period, for every account. There is no partial credit, which matches lesson 0.2: one untested account makes the statement other than satisfied, whatever happened with the others.

The method is examine. An interview with the person who tests the accounts would be useful for understanding the control, but a person's account of a test is weaker than the record of one, and the clause requires a record. If the record exists, examining it decides the statement; if it does not, no interview can supply it.

The evidence requested is named precisely: the test records for the period and the privileged role assignment export. A vaguer request, such as "evidence of emergency access testing", invites a policy document or a screenshot of the account.

A second assessor reading this row should be able to run the same test and reach the same result without asking you anything. That is the standard to hold every row to: the statement, the population and the acceptance are specific enough that two people could not reasonably apply them differently.

Every column of the row is filled before any file is opened.

Filling every column first is what makes the acceptance criterion a test, rather than a description of whatever the files turned out to show.

Before testing any account, establish which accounts there are. Five items in the pack say something about emergency access accounts, and they do not all agree.

Four sources, three of them generated by the directory itself, agree on one account: emergency-access-01@ne.onmicrosoft.com. The standard says two. Every system source points to the same single account, and none names a second.

There are two possible explanations, and the evidence does not choose between them. Either a second account exists but is missing from every export supplied, which would make those exports incomplete, or it was never created or has been deleted, which would make the standard and the tenant disagree. Each is a different problem, and both belong to clause 3, privileged access, which governs which accounts hold administrative roles.

For EA-04.1 the population is the one account the directory shows. The difference with the standard goes into the workpaper as a scope note and is referred to the privileged access statements, where it will be decided on its own evidence. That keeps this determination clean: it is about testing, and it is decided on the accounts that the records show exist.

The referral is not a way of dropping the issue. A missing emergency access account is serious in its own right, and it will reach the report through the privileged access determination. It reaches it once, through the statement that the evidence actually bears on.

This is a pattern you will meet throughout the course. One fact often bears on several controls, and the temptation is to record it under each of them. Deciding it once, under the statement it actually answers, and cross-referencing it from the others keeps the report from counting one problem several times and keeps each determination about one thing.

Counting the population from several sources also shows how much the organization's own records agree with each other. Four sources naming the same single account is a reassuring sign about those exports, even though it leaves the standard and the tenant in disagreement. Agreement between independent records is worth noting whenever it appears, because it is what makes a population trustworthy.

The test records and the role assignment export arrived in response to the request. Before reading them closely, each goes into the evidence register with its source, coverage and the three judgments from lesson 0.4.

The judgment on E-11 matters most. The test record is kept by people, not generated by a system: someone in IT Operations writes a row when a test is run. That makes it the right evidence for "the test recorded", because it is the record the clause asks for, but it also means it can only show tests that someone chose to record.

E-12, the role assignment export, is generated by the directory, which is why it supplies the population. E-13, the standard, is the criteria document, and it is registered like any other item so that the workpaper can cite the exact version tested against.

Each entry gets the date it was received and a hash, as lesson 0.3 described. If the test record is later corrected, with a row added for a test someone forgot to enter, the original stays in the register beside the corrected version, so the report can say what was supplied and when.

Registering the standard as evidence also fixes which version the determination was measured against.

Each judgment in the register is written for the use the item will be put to. E-11 is relevant to the whole statement, reliable as the organization's own record of its tests, and complete only as far as the people keeping it recorded every test.

E-12 is relevant to the population, reliable because the directory generated it, and complete for the tenant on the date it was exported. Writing the judgments this precisely lets the workpaper rely on each item for one purpose without overreaching. Module 4 takes each judgment in turn.

With the evidence registered, the test record can be read row by row, starting with what the file holds and what it covers.

account,testDate,result,testedBy
emergency-access-01@ne.onmicrosoft.com,2026-03-12,Pass,m.webb

The file holds one row. The account is the one in the population, the test is recorded as a pass, and it was carried out by m.webb. The date, 2026-03-12, falls in the first quarter of 2026. Nothing in the file is dated between 2026-07-01 and 2026-09-30.

Read the record for what it shows, and only that. It shows that a test was run and recorded in March. It does not show that the account worked on 30 September, and it says nothing about the second quarter either, since no test is recorded between March and the end of September.

The second quarter is outside this assessment's period, so the assessment does not conclude on it, but the gap of 202 days between the last test and the end of the period is a fact the condition can state.

Check what the file covers before reading its silence as an absence. The register records it as every test IT Operations holds, of any date, and the request asked for test records for the period. A file filtered to the period would have been empty; this one was not filtered, which is why the March test appears at all. Either way, the record contains no test in the period.

The row also names who ran the March test. m.webb holds administrative roles of his own, so the person testing the emergency access account is one of the administrators it exists to back up.

That is not a requirement of clause 4, and it does not affect this determination, but it is the kind of detail worth noting for the interview: who is responsible for the test now, and what reminds them to run it.

The evidence card shows the record as it was supplied, before anyone decided what it proves. That is the habit to keep: read the file, its source and its coverage first, and only then decide which statement it bears on and what it shows.

Before deciding, ask what further evidence could move the determination, and whether any of it should be requested. This is the step that separates a deficiency from a determination the evidence cannot make: if a plausible piece of evidence could still show the statement holds, the right answer may be to request it rather than decide.

Only one row could change the answer: a test record kept somewhere else and missed by the export. That is worth one question to the control owner, put plainly: is there any other record of emergency access tests? The answer goes in the interview notes. For this pack, the record supplied is the only one IT Operations holds, so the question settles nothing new.

Sign-in logs would be interesting but cannot help. Even if they showed someone signing in to the account in August, the clause requires the test to be recorded, and an unrecorded sign-in is not a recorded test. Requesting them would add work without changing the outcome.

Some things you notice along the way are outside the statement altogether. The MFA registration export shows the account registered with push notifications to an authenticator app. Whether that is a good method for an emergency account is a fair question, but nothing in clause 4 addresses it. Record it as an observation for the report, separate from any determination, and do not let it shape this one.

Observations are a legitimate part of a report, as long as they are labeled as such. They tell the reader something the assessor noticed that no criterion in scope addressed, and they carry no determination value.

Mixing one into a finding, by citing the authentication method as part of the consequence of a missing test, would make the finding harder to validate and easier to dispute, because the control owner could rightly say the standard asks for no particular method. Keeping the two apart lets each be judged on its own.

Writing the list before deciding also makes the reasoning visible to a reviewer, who can see which possibilities were considered and why each one was set aside.

Everything needed for the determination is now in hand, and it goes onto the workpaper in the order the test matrix row set out: criterion, statement, method, population, evidence and result.

The value is other than satisfied, and the reason is deficiency. The evidence does not leave the statement open: the organization's own record of tests contains no test in the period for the only emergency access account the directory shows. The clause requires a recorded test, and there is none.

The scope note in the result is part of the determination. A reader of the workpaper can see that the population was one account, that the standard expects two, and that the difference was sent elsewhere rather than ignored.

If the second account turns up later, untested, the determination does not change, because one untested account is enough. If it turns out never to have existed, this determination does not change either. Either way the workpaper stays true.

That is the test of a well-scoped determination: new facts about adjacent questions should not overturn it. A workpaper that depended on how many accounts there ought to be would have to be rewritten as soon as the privileged access statements were decided. This one depends only on the records of the account that exists and the test that was not recorded.

Compare the cannot-determine outcome from lesson 0.2, the ERP restore. There the evidence was silent on the thing the statement asked about. Here the evidence is the very record the statement asks for, and it shows the requirement was not met.

A determination like this one is quick to reach once the steps before it are done. Most of the work was in reading the clause, fixing the population and checking the record's coverage. The decision itself follows directly from those, which is how it should be: a determination that needs long argument at the end usually means a step earlier was skipped.

A determination of other than satisfied with the reason deficiency becomes a finding. The draft follows the findings template from lesson 0.4.

The condition states the fact with its numbers and nothing more. The consequence says what the gap makes possible, kept specific to this account. The cause is not established, because nothing in the evidence explains why no test was recorded after March.

The severity is proposed, not final. High rests on what the account is for: it is the route back into the tenant when everything else has failed, and the second account that would provide a fallback is not in any export. Module 9 covers severity properly. For now, the habit is to write the rationale beside the rating, so that the control owner can dispute either one separately.

The draft then goes to the Head of IT Operations for validation. That is where a missing record would surface, if one existed, and where the owner can explain the cause. Once validated, the finding goes into the report, with a corrective action and a retest on a later quarter.

The corrective action is the control owner's to propose, not the assessor's to write. What the assessor contributes is the closure evidence required: a recorded sign-in test of each emergency access account, dated in the quarter after the fix. When that record exists for every account in the directory, the retest can decide EA-04.1 again on the new period.

That completes the path: a clause read closely, a row written before the evidence, a population taken from records, evidence registered and read, a check for evidence that could change the answer, a determination with its reason, and a draft finding. Every control in this course is assessed the same way.

Each of those steps is one this course returns to, in depth, in a module of its own.

Module 1 starts from the beginning of an assessment rather than the middle: what assurance means, who relies on it, and what an assessment can and cannot conclude. Its exercise asks whether a reported MFA coverage figure of 98 percent can be relied on.