Lesson Overview
Everything taught so far in this course has been about granting access and protecting it: identity as the master key, the account lifecycle, authorisation by role, the safekeeping of secrets, the security of a state's records, the control of privileged access, federation across systems, the classification and lifecycle of data, and the protection of the privacy of nationals. This final lesson is about the part that holds all of it honest. Access that no one can see, no one reviews, and no one is answerable for is not really controlled at all. It is merely permitted and forgotten. Audit, review, and accountability are how a small force keeps its grip on who may do what, proves it afterwards, and catches the gaps before they are exploited.
The work has three plain strands. First, logging: recording who accessed or changed what, protecting those logs from tampering, and reviewing them, so that misuse becomes visible and accountability has something to rest on. Second, review: the routine, recurring check, first met in Lesson 02, that everyone still needs the access they hold, which catches privilege creep and orphaned accounts before they become a way in. Third, the framework's special-access rule stated plainly: holding a qualification never grants access, an appointment does, and access is revoked promptly when the appointment ends. The lesson then draws the whole course together, identity, access, secrets, records, and audit, into one accountable system, and points on to CIS 310, which begins where an audit reveals that something has gone wrong.
A word on scope, the same one this course has carried throughout. This is the knowledge layer. The real work, configuring logging on a live service, sitting down to an actual access review, running a reporting drill when a log shows something odd, is done and signed off in person, under supervision, where the College and the system's owner allow it. Learn here why audit matters and what a good one looks like, so that when you are appointed to do it, you do it knowingly.
By the end you will be able to explain why logging, log protection, and log review make access visible and support accountability; describe what a useful audit-trail entry contains and how audit trails make misuse detectable; run and explain a periodic access review or recertification that catches privilege creep, orphaned accounts, and excess; state plainly the rule that access follows appointment and not qualification and is revoked when the appointment ends; tie together identity, access, secrets, records, and audit as one accountable whole; and recognise the point at which audit reveals an incident and the work passes to CIS 310.
Key Terms
- Audit trail (audit log): a protected, time-ordered record of who did what, to what, and when, kept so that access and changes can be reviewed and accounted for after the fact.
- Logging: the act of recording security-relevant events, such as a sign-in, a permission change, or a record being read or edited, into a log.
- Log integrity: the assurance that a log has not been altered or deleted; a log a person can quietly edit is worthless as evidence.
- Accountability: the principle that every action can be traced to a responsible, named person, so that no one can act under cover of anonymity and so that good and bad conduct can both be attributed fairly.
- Non-repudiation: the property that an actor cannot credibly deny having taken a recorded action, because the audit trail ties the action to their identity.
- Access review (recertification): a periodic check in which the owner of a system or record confirms, account by account, that each person still needs the access they hold, and that access not confirmed is removed.
- Privilege creep: the quiet accumulation of access an account no longer needs, as a person moves between roles and access is added but never taken away; the chief thing reviews exist to catch.
- Orphaned account: an active account with no current, responsible owner, such as one left behind by a leaver or a shared login no one is answerable for; a common and dangerous way in.
- Appointment: the formal assignment to a duty or post that, alone, grants access to the systems and records that duty requires; distinct from a qualification, which proves only competence.
Why access must be visible: logging and the audit trail
Control of access is only half of the discipline. The other half is being able to see how access was actually used, and to prove it afterwards. A force can grant access carefully by every rule in Lessons 02 to 05 and still be blind, if no record is kept of what was done with that access once granted. Logging is what removes the blindness. To log an event is to record, at the moment it happens, that it happened: a sign-in succeeded or failed, a permission was changed, a record was opened, a secret was retrieved from the vault, a national's personal data was edited. Gathered and kept, these records become the audit trail, the time-ordered account of who did what to what, and when.
The audit trail does two jobs that nothing else can. It makes misuse visible: the only way to notice that an account read three hundred national records at two in the morning, or that someone granted themselves admin rights they were never appointed to hold, is to have logged it and to look. And it supports accountability: because each action is tied to a named identity, every action can be traced back to a responsible person. That traceability is why identity, taught in Lesson 01 as the master key, matters here too. A log is only as good as the identities behind it. If three people share one login, the log can tell you the login acted but not which person did it, and accountability collapses into a shrug. This is one more reason the course has insisted throughout on individual accounts and against shared ones: accountability needs a name, not a role played by an unknown hand.
A useful log entry is specific. It answers, at a minimum, who, what, to what, when, and from where. A line that says only "record changed" is nearly useless; one that ties a named account, a precise action, a specific record, an exact time, and an origin together is evidence.
ANATOMY OF AN AUDIT-TRAIL ENTRY
2026-06-11 02:14:07Z cpl.adeyemi UPDATE person_record:10482
field: home_address old: [redacted] new: [redacted]
via: gov-portal source-ip: 172.18.0.5
session: 7f3a...c19 result: SUCCESS
WHO cpl.adeyemi ......... a NAMED individual account, not a
shared login; accountability has a name
WHAT UPDATE .............. the action taken
TO WHAT person_record:10482 the exact object acted upon
WHEN 2026-06-11 02:14:07Z precise, in a single time zone (UTC)
WHERE via / source-ip ..... the service and origin of the action
RESULT SUCCESS ............. did it actually happen, or was it denied
Read this line a week later and you know exactly what occurred,
who is answerable for it, and whether it should have happened at all.
"record changed" tells you none of that. Detail is what makes a
log evidence rather than noise.
Three disciplines make logging worth doing. Log the right things. You cannot log everything without drowning the signal, so log the security-relevant events: authentications (especially failures), changes to access and permissions, use of privileged and admin accounts, reads and writes of sensitive records, and retrieval of secrets. Keep the clocks honest. An audit trail across several services is only coherent if their clocks agree, so synchronise time and record it in one zone, UTC by convention, or two logs of the same incident will never line up. Keep logs long enough. A misuse may not be noticed for weeks, so logs must be retained long enough to investigate, balanced against the storage-limitation principle from Lesson 05: keep them as long as there is a genuine need to, and no longer.
Protecting the logs themselves
A log that the person being audited can quietly edit is no log at all. The first thing a careful wrongdoer does is reach for the record of what they did. So log integrity, the assurance that the trail has not been altered or deleted, is not an optional refinement; it is what makes the whole exercise meaningful. An audit trail is evidence, and evidence that the suspect could have rewritten proves nothing.
Protecting logs draws on the same principles as protecting any sensitive record, sharpened by the fact that the people most motivated to tamper are insiders with access. The chief measure is separation: the people who can act in a system should not be the same people who can edit its logs, and ideally cannot reach the logs at all. Logs should be shipped, as they are written, to a separate, append-only store that ordinary operators and even most administrators cannot alter or delete, only add to and read. Restrict who can read logs, too, because a log of who accessed nationals' data is itself sensitive personal data and falls under everything Lesson 05 taught. Apply least privilege and need to know to the audit trail as strictly as to anything else. And protect logs in transit and at rest with the same encryption you would give any sensitive record.
WHY LOGS GO SOMEWHERE THE ACTOR CANNOT REACH
WITHOUT SEPARATION (weak) WITH SEPARATION (sound)
.------------------------. .------------------------.
| service | | service |
| | writes log | | | writes log |
| v | | v |
| log file <-- operator | | log --ship--> [ APPEND-ONLY
| can EDIT or | | (one way) LOG STORE ]
| DELETE it | | separate owner,
'------------------------' | add + read only,
the actor can erase the | no edit/delete
record of their own action '------------------------'
the actor cannot rewrite history
An audit trail is evidence. Evidence the suspect could have
altered proves nothing. Whoever can ACT must not be whoever
controls the LOG of that action.
Logs are not write-only archives, either. The third discipline, and the one most often neglected, is to actually review them. A log no one ever reads detects nothing; it only provides a sad, complete record after the harm is done. Reviewing logs means looking, on a regular rhythm and when something prompts it, for the patterns that signal trouble: repeated failed sign-ins, access at odd hours, an account reaching for records far outside its duties, a privileged account used where it should not be, a secret pulled from the vault by someone with no current reason. Small forces cannot watch every line by hand, so the practical approach is to alert on the few events that almost always matter and to set aside a regular slot to review the rest. The point is not to read everything; it is to make sure something competent and accountable is looking.
The access review: catching creep, orphans, and excess
Logging tells you how access was used. The access review asks a different and equally vital question: should this access exist at all, still, today? You met this in Lesson 02 as the closing discipline of the account lifecycle, and it is worth reinforcing here because it is the single routine that keeps access from quietly rotting over time. Grants are easy to make and easy to forget. People join, change roles, take on extra duties, hand duties back, and leave. At every step access tends to be added and tends not to be removed, because adding solves an immediate problem and removing solves only a future one no one is feeling yet. Left alone, the result is privilege creep: accounts accumulating rights they no longer need, and the slow drift of a tidy access scheme into a sprawl no one understands.
The access review is the deliberate counter-drift. On a set rhythm, quarterly is a common and sensible cadence for a small force, the owner of each system or record set goes through its accounts and recertifies them, one by one. For each account the owner answers a few plain questions, and access that cannot be positively confirmed is removed, not left in doubt.
THE PERIODIC ACCESS REVIEW (RECERTIFICATION)
For each account with access to this system or record set:
( 1 ) Is there still a real person behind this account?
NO -> ORPHANED. Disable and remove. Who owned it?
( 2 ) Does that person still hold the appointment that
justified this access?
NO -> appointment ended; access should already be
gone. Remove now, and ask why it was missed.
( 3 ) Does the access still match what the role needs today?
MORE THAN NEEDED -> PRIVILEGE CREEP. Trim to least
privilege. Especially: still hold admin rights?
( 4 ) Is this a leftover from an old role, project, or
one-off task that has finished?
YES -> remove it.
DEFAULT: access not positively re-confirmed is REMOVED.
The review is owned by the system owner, not self-certified
by the holder, and the whole pass is logged for accountability.
Two findings recur in every honest review, and both are dangerous. The first is privilege creep, already described: the answer to "does the access still match the role?" comes back "no, it has more than it needs", usually because a temporary grant became permanent or an old role's rights were never stripped when the person moved. The review trims it back to least privilege. The second is the orphaned account: an active account with no current, responsible owner. A leaver whose deprovisioning was missed, a contractor's login left enabled, a shared service account no person is answerable for. Orphaned accounts are a favourite way in precisely because no one is watching them; nobody notices the login because nobody owns it. The review finds them by asking, of every account, "who, by name, is responsible for this, and do they still need it?", and disabling any account that cannot answer.
Two principles keep reviews honest. The owner certifies, not the holder: a person asked "do you still need your access?" will almost always say yes, so the responsible owner of the system makes the call against the role's actual need. And the review itself is logged, because a review is an exercise of authority over access and is, like all such, subject to audit. A review that left no trace cannot itself be accounted for.
The special-access rule: appointment, not qualification
All of this rests on a single rule from the specialities framework, and this lesson is where it lives most plainly. Access follows appointment, not qualification. Completing a course, holding a certificate, or being skilled at a thing proves that a person can do it. It does not, and must not, grant them access to the live systems or real records that the duty involves. Access to those comes only with the formal appointment to the duty, made by the authority responsible for the system or record, and it ends, promptly, when the appointment ends.
The distinction is not bureaucratic fussiness; it is the whole logic of accountable access. A qualification is a property of a person and travels with them for life. An appointment is a property of a duty and is held only for as long as the duty is. If access tracked qualification, then every member who ever completed this course would carry access to the registers of the Principality for the rest of their lives, whether they currently serve in a role that needs it or not, and the access scheme would become an ever-growing pile that no review could ever clear, because every holder could rightly say "but I am qualified". Tying access to appointment instead means access exists exactly when there is a current, answerable reason for it, and not a day longer. It is what makes the leaver step of Lesson 02 enforceable, what gives the access review something firm to certify against, and what makes accountability possible at all: the audit trail can ask not only "who did this?" but "were they appointed to be able to?"
ACCESS FOLLOWS APPOINTMENT, NOT QUALIFICATION
QUALIFICATION APPOINTMENT
"I am trained to do this" "I am posted to this duty"
.------------------------. .------------------------.
| a property of the | | a property of the DUTY |
| PERSON | | |
| held for life | | held only WHILE in the |
| | | post |
| proves COMPETENCE | | grants ACCESS |
'------------------------' '------------------------'
| |
| completing this course | appointment by the
| grants NO access | system's owner grants
v v the access the duty needs
does not unlock unlocks the access...
the registers ...and access is REVOKED
promptly when the
appointment ENDS
Skill says a person CAN. Appointment says they currently MAY.
The two are deliberately different. No member gains access by
passing CIS 220; access comes only with the appointment.
So, plainly: passing this course grants you no access to anything. When you are appointed to a duty that requires access, the authority responsible for that system grants you exactly the access the duty needs, no more, by role; that grant and its use are logged; the access is reviewed on a rhythm to confirm you still need it; and the moment your appointment ends, the access is revoked promptly, whatever qualifications you keep. That single sentence is the whole of accountable access in miniature.
One accountable whole: drawing the course together
Step back now and see the six lessons of this course as one system, because none of them stands alone. They are a single chain, and accountability runs through every link.
Identity (Lesson 01) is the master key: every action begins with proving who you are, and every log entry, every review, every grant is anchored to a named identity. Protect it above all, because most breaches are stolen or misused credentials. The account lifecycle (Lesson 02), joiner, mover, leaver, governs the existence of access over time, with orphaned and dormant accounts hunted down. Authorisation (Lesson 03) governs its shape: least privilege and need to know, granted by role through RBAC, with separation of duties so no one controls a whole sensitive process, and admin rights kept separate and just in time. Secrets (Lesson 04), the passwords, tokens, certificates, and private keys such as the per-user TAK .p12, are kept in a vault, rotated on a schedule and on departure or compromise, and revoked at once when lost. Records (Lesson 05), the registers of the Principality and above all nationals' personal data, are what all of this protects: classified, encrypted at rest and in transit, kept only as long as lawfully needed, handled by the data-protection principles so privacy is the default.
And audit (this lesson) wraps the whole: it makes every link of the chain visible, reviewable, and accountable, and proves the others are actually being honoured.
CIS 220 AS ONE ACCOUNTABLE SYSTEM
+-------------------------------------------------+
| AUDIT |
| logs every action, protects the logs, |
| reviews access, accounts for it all |
| +-------------------------------------------+ |
| | IDENTITY (L01) the master key; a name | |
| | on every action | |
| | | | |
| | v | |
| | LIFECYCLE (L02) joiner / mover / leaver | |
| | | | |
| | v | |
| | AUTHORISATION (L03) least privilege, | |
| | RBAC, separation of duties | |
| | | | |
| | v | |
| | SECRETS (L04) vault, rotate, revoke | |
| | | | |
| | v | |
| | RECORDS (L05) classify, encrypt, | |
| | minimise, protect nationals' privacy | |
| +-------------------------------------------+ |
| governed throughout by: ACCESS FOLLOWS |
| APPOINTMENT, NOT QUALIFICATION |
+-------------------------------------------------+
Remove any one layer and the others leak. Audit is the layer
that proves all the rest are real.
This is the partner discipline of SIG 220 (Communications Security and Digital Discipline), which carries the same mindset onto the wire; it supports PME 210 (Basic Staff Duties and Written Orders), whose custody of records this course secures; and it draws on HCR 220 (continuity and resilience). It is defensive and lawful from end to end: it protects Kaharagia's accounts, keys, records, and the privacy of its nationals, and it is never a course in cracking credentials, escalating privilege, or reaching records without authority.
When audit reveals an incident: the bridge to CIS 310
Audit has a further purpose beyond steady-state accountability, and it is the natural close of this course. Often the audit trail is the very thing that first shows something has gone wrong. A review turns up an admin account no one appointed. A log shows a national's records read in bulk at three in the morning by an account with no reason to. A secret was retrieved from the vault by a person who left the force a month ago. At that moment the discipline of this course hands over to the discipline of the next. Audit detected the event; CIS 310, Cyber Incident Response and Continuity, is what you do about it.
The handover follows the ordinary member's drill that runs through this whole speciality, and it is worth fixing in mind as the last thing this course teaches. When audit reveals something wrong: recognise it for what it might be; report it at once through the proper channel, never sit on it; do not tamper, do not try to fix or quietly clean up, because doing so destroys the very evidence the audit trail exists to preserve; preserve the logs and the state as they are; and follow direction from those handling the response. The protected, tamper-evident audit trail you built in this lesson is precisely what makes a sound response possible: it is the record that lets responders see what happened, scope the damage, and hold the right people to account. A force that logged nothing, or logged into a place the wrongdoer could erase, walks into an incident blind. A force that audited well walks in with the facts already in hand.
That is the join. Lesson 10 ends where CIS 310 begins, at the moment accountability stops being routine and becomes response. Identity, access, secrets, records, and audit, kept honestly day to day, are what make that response survivable.
In Practice: A Quarterly Review Turns Up Two Findings
A systems assistant, recently appointed to help administer the force's identity service, is tasked with running the quarterly access review of the government portal that operators use to work with nationals' records. It is unglamorous work, an exported list of accounts and their access, and the assistant settles in to go through it line by line against the rule that access follows appointment.
Two findings emerge, and they are the two this lesson promised. The first is an account, temp.records.import, with broad write access to the person register. No named individual owns it; it was created months ago for a one-off data import and never disabled. It is an orphaned account with standing access to nationals' personal data, answerable to no one, exactly the kind of thing an attacker hopes to find. The second is a corporal who moved six months ago from a records role into a logistics one, yet still holds their old read access to the full register. The logistics role has no need of it. This is privilege creep: access added for a former duty, never removed on the move.
THE ASSISTANT'S REVIEW: TWO FINDINGS, TWO ACTIONS
FINDING 1 temp.records.import -- no human owner, broad write
orphaned account, leftover from a finished import
ACTION: disable now; trace who created it and why
it survived; recommend such jobs use
time-limited, owned, just-in-time access
RULE: no current appointment behind it -> no access
FINDING 2 cpl moved records -> logistics, kept register read
privilege creep from an old duty
ACTION: remove the register access the new role
does not need; trim to least privilege
RULE: access follows the CURRENT appointment
AND: the assistant does NOT self-certify their own access.
The whole review is itself LOGGED, so the review is accountable.
The assistant does the right thing in the right order. They do not quietly delete the orphaned account, which would erase its history; they disable it, preserve its record, report the finding, and ask how a job like that should have been done, with a time-limited, owned, just-in-time grant rather than a standing one. They trim the corporal's leftover access back to what the logistics role needs, against the role and not against the corporal's protest that it is handy to keep. They do not certify their own access; the owner of the portal does that. And the whole pass is logged, so that the review itself can be accounted for later. A quarter on, the next review is shorter, because this one closed the gaps instead of letting them grow. That is the quiet, recurring work on which a digital state's safety actually rests.
Check Your Understanding
- Explain what makes an audit trail useful for both detecting misuse and supporting accountability, and why individual named accounts (rather than shared logins) are essential to it. What, at a minimum, should a single log entry record? Then explain why log integrity matters so much, and what separation of duties between acting in a system and controlling its logs achieves.
- Describe the periodic access review and the two findings it most reliably turns up, privilege creep and the orphaned account, including how each arises and what the review does about each. Why must the system's owner certify access rather than the holder, why is "not positively re-confirmed means removed" the right default, and why is the review itself logged?
- State the rule that access follows appointment and not qualification, and explain the difference between a qualification and an appointment that makes the rule necessary. Why would tying access to qualification make the access scheme impossible to keep clean, and what does tying it to appointment make enforceable across the joiner-mover-leaver lifecycle and the access review?
Reflection (write a short paragraph): This lesson argues that access which no one can see, no one reviews, and no one is answerable for is not really controlled at all, only permitted and forgotten. Think about a system you use or help run, in the Army or out of it, that holds information about other people. Could you say, honestly, who has access to it, why each of them has it, and how you would prove after the fact who did what? Where are the gaps: a shared login no single person is answerable for, an account left active for someone who has moved on, access someone holds because they once needed it rather than because they need it now? Then turn it on yourself and your own future appointment. When you are one day given access to the registers of the Principality, what will it mean to you that the access came with the appointment and must end with it, that everything you do with it is logged, and that you are personally answerable for every one of those actions by name?
Summary
- Controlling access is only half the discipline; the other half is making its use visible and accountable. Logging records who accessed or changed what, audit trails make misuse detectable and tie every action to a named, responsible identity, and that traceability is why individual accounts (Lesson 01) matter and shared logins fail.
- A useful log entry records who, what, to what, when, and from where, and whether it succeeded. Log the security-relevant events, keep clocks synchronised in one time zone, and retain logs long enough to investigate while respecting storage limitation (Lesson 05).
- Logs are evidence, so protect their integrity: ship them to a separate, append-only store the actor cannot edit or delete, restrict who may read them (they are sensitive data too), and, above all, actually review them, because a log no one reads detects nothing.
- The periodic access review (recertification), first met in Lesson 02, is the routine that counters drift. The owner recertifies each account against current need; access not positively confirmed is removed. It reliably catches privilege creep (access that outgrew the role) and orphaned accounts (active logins with no responsible owner), and the review itself is logged.
- Access follows appointment, not qualification: a qualification proves competence and is held for life, while an appointment grants access and is held only for the duty's duration. Passing this course grants no access; access comes with the appointment and is revoked promptly when it ends. This is what makes the leaver step and the access review enforceable.
- The six lessons are one accountable system: identity (L01), lifecycle (L02), authorisation (L03), secrets (L04), and records (L05), with audit wrapping all of them and the appointment rule governing throughout. Remove any layer and the others leak. It is the partner of SIG 220, supports PME 210, and is defensive and lawful from end to end.
- Audit often detects an incident first; when it does, this course hands over to CIS 310 (Cyber Incident Response and Continuity). The member's drill is recognise, report at once, do not tamper, preserve the evidence, and follow direction. The protected, tamper-evident audit trail built here is exactly what makes a sound response possible.
Crown Copyright © 2026 | Published by Authority of H.R.H. The Prince of Kaharagia