Study Guide
Security Documentation
The different jobs of policies, standards, procedures and guidelines.
Lesson 5.2 Governance, Risk & Compliance
Decisions about security only work if people know what they are and can follow them. This lesson works out which kinds of document carry decisions to the people who carry them out, how records show afterwards what actually happened, and how to keep documents useful rather than just filed.
Stage: Think
The school trip
Think it through
A school organises a trip. Think of four kinds of written guidance it might have: one saying what must be achieved, one with exact rules that can be checked, one with the steps in order, and one with helpful advice. Write an example of each.
- Hint 1: Which of them could be checked with a yes or no?
- Hint 2: Which could a teacher choose to do differently?
Show what happens
For example: every trip must be safe and supervised; at least one adult for every ten pupils; fill in the form, get it signed, collect consent slips; tips for keeping a group together on a train. Those are four different kinds of document.
Think it through
Show the answer
Answer: C. Yes: tips are advice, not rules.
Yes. Advice can be set aside for a good reason; rules cannot. That difference is the first distinction in this lesson.
Stage: Explain
Four useful distinctions
A school already has all four kinds of document, for something that has nothing to do with computers: a school trip.
- The school’s rule that every trip must be safe and properly supervised is a policy. It says what must be achieved and who is responsible. It does not say how.
- At least one adult for every ten pupils, and a first-aider on every trip is a standard. It is specific, it can be checked, and it is compulsory.
- Fill in the trip form, get the deputy head’s signature, collect consent slips, hand the list to the office is a procedure. It is the steps, in order, with who does each.
- Tips for keeping a group together on public transport is a guideline. It is advice. A teacher may do it differently if they have a good reason.
Security documents work in exactly the same way.
| Document | The question it answers | Compulsory? |
|---|---|---|
| Policy | What do we intend, and who is responsible? | Yes |
| Standard | What exactly must be true? | Yes |
| Procedure | What are the steps, and who does each? | Yes |
| Guideline | What is a good way to go about it? | No: it is advice |
Read from the top: each kind is supported by the one beneath it, and there are more documents at each level going down, with a few policies and many procedures. The school examples are fictional.
Policy · What we intend
“Pupils’ information must be protected, and each record has a named member of staff responsible for it.”
is supported by
Standard · What must be true
“Every staff laptop must be encrypted. Remote sign-in must use multi-factor authentication.”
is supported by
Procedure · The steps
“To request access to pupil records: 1. the head of department completes the form; 2. the deputy head approves it; 3. IT sets it up and records the date.”
is supported by
Guideline · Good advice
“How to choose a passphrase you can remember.”
Check your understanding
Show the answer
Answer: A. Standard
A standard: it is specific, it can be checked, and it is compulsory.
Two cautions. The names vary between organisations, so look at what a document does, not at its title. And a guideline can never be used to get round a standard: advice does not outrank a rule. (An organisation’s own standard is also a different thing from an international standard such as those in a later lesson.)
Think it through
A blank access-request form, and the same form filled in, approved and dated. What is the difference between them?
- Hint 1: Which one could you show an auditor?
Show what happens
The blank form is a template: it says what should happen. The completed one shows what did happen, so it is evidence.
Records do a different job from all four. A document says what should happen; a record shows what did. A blank access-request form is a template. The same form filled in, approved and dated is a record. Records are the evidence, and a document alone is never proof that anything was done.
Stage: Predict
A fictional access-management example
A fictional school needs its staff to have the access their job requires, and to lose access they no longer need when they change role or leave. Four documents work together.
- Policy: access must be authorised, must match the person’s responsibilities and must be reviewed. The deputy head is responsible. Exceptions need her approval.
- Standard: every member of staff has their own account, and nobody shares one. Remote access uses multi-factor authentication.
- Procedure: how a manager requests access, how it is approved, how IT sets it up, and how it is changed or removed when someone moves or leaves.
- Guideline: how to choose and set up a sign-in method from those the standard allows.
Think it through
A teacher moves to a new role in the same school. Which two things should happen to their access, and how would anyone know later that both happened?
- Hint 1: Is adding access the only change?
Show what happens
They should gain what the new role needs and lose what it no longer needs. Records of the request, approval and change, and a later check of what the account can really open, show whether both happened.
Follow one role change
Mr Osei moves from teaching science to being head of year. He needs pastoral records and no longer needs the science department’s budget folder.
- The request. His manager submits the role-change form: the date of the move, the access he now needs and the access to remove. The procedure requires both lists. “Give him the same as the last head of year” is not accepted.
- The approval. The deputy head approves the new access. That approval is a record.
- The change. IT adds the pastoral access, removes the budget folder and records the date. That is a second record.
- The check. At the half-termly review, someone compares what Mr Osei’s account can actually open with what was approved. They find that he can still open the science budget folder: it was reached through a group that the form never mentioned.
- The correction and the cause. The access is removed. The cause is that the form lists folders and not groups, so the procedure and the form are both updated, and managers are told.
Check your understanding
Show the answer
Answer: C. It showed a report, not a check.
A closed request records that an action was reported. Only the later check compared what the account could open with what was approved.
What the three records show. The approval shows that someone with authority agreed. IT’s record shows what was reported as done. Neither showed that the result was right: only the check in step 4 did. A closed request is evidence that an action was reported, not proof that the permissions are correct. Together the three support accountability and least privilege.
Stage: Predict
Keeping documents useful
Think it through
Why might an out-of-date procedure be worse than having no procedure at all?
- Hint 1: What do people do with a document they trust?
Show what happens
Because people believe it and follow it, carrying out steps for a system that has changed. With no procedure, at least they know to ask.
A document that nobody can find, or that describes last year’s system, is worse than none, because people believe it. Each one needs:
- an owner, who is responsible for keeping it right;
- a stated audience;
- a clear current version, with old versions removed or marked as replaced, so that nobody follows the wrong one;
- approval by someone with the authority to give it;
- a review date, and a note of what would trigger an earlier review.
A document managed in this way is called a controlled document.
Involve the people who have to follow a procedure when it is reviewed. A beautifully written procedure fails if the system it describes has changed. Tell people when a document changes and check that they have understood: a tick in a box saying “I have read this” does not show that.
Records need looking after too. Protect them from being read or altered by the wrong people, keep them as long as they are needed and no longer, and never rewrite an old approval to match what happened later.
These practices support governance oversight and consistent work. They do not replace checking the controls themselves.
Stage: Explain
Records that support decisions
Some records exist to explain why something was decided. When an organisation decides what to do about a risk, the record of that decision connects the risk, how serious it was judged to be, what was chosen, who is responsible and when it will be looked at again. Treating Risk shows one.
Check your understanding
Show the answer
Answer: B. What was actually done by then.
What was actually done, recorded separately from the plan, and never by rewriting the original entry.
Meeting minutes, approved exceptions, access reviews and records of corrective action do the same job. A good record separates what is planned from what has been done. Many records are not better evidence than a few accurate ones.
Stage: Predict
Documentation lifecycle
Think it through
A new procedure has just been published. What still has to happen for it to work?
- Hint 1: Does publishing a document change what people do?
Show what happens
People have to be told about it and understand it, it has to be followed, and it has to be reviewed against what really happens and then improved.
A document is not finished when it is published. The access procedure from Mr Osei’s move went through every one of these stages, and step 5 of Mr Osei’s move sent it round again.
A document supports security when its instructions are authorised, understood, used and improved, one stage at a time. Changes return through the relevant approval and communication stages.
Creation
Step 1 of 6: Draft it with its users
Draft the access procedure with its owner, requirements, roles and practical steps. Involve the people who will use it.
Approval
Step 2 of 6: Authorise a controlled version
An authorised decision-maker checks suitability and approves a controlled version before use.
Communication
Step 3 of 6: Make it known
Make the current version accessible and explain changes through appropriate guidance and training.
Implementation
Step 4 of 6: Follow it and keep records
Follow the approved process and retain appropriate records of decisions and actions.
Review
Step 5 of 6: Compare it with real work
Compare instructions with actual work, exceptions and control results. Check whether responsibilities and requirements have changed.
Improvement
Step 6 of 6: Correct and repeat
Correct gaps, revise the document and repeat approval and communication where needed. Check that the change works.
Improvement leads back to creation and approval. The PDCA access-management example in a later lesson connects this to a wider cycle of planning, doing, checking and acting.
Stage: Predict
Statement of Applicability
One document deserves a section of its own, because it is specific to a widely used international standard and is often misunderstood.
Three terms are needed first. Each is taught fully in Security Frameworks and Standards; a sentence each is enough here.
- ISO/IEC 27001 is an international standard for managing information security. An organisation can be independently checked against it and certified.
- An ISMS (information security management system) is what that standard asks for: the organisation’s whole arrangement of policies, responsibilities, risk decisions and checks for looking after information. It is a way of managing, not a piece of software.
- Annex A is a list at the back of the standard of about ninety possible security controls, to compare against.
Think it through
A standard lists about ninety possible controls, and an organisation does not need all of them. What would you want written down about each one?
- Hint 1: Would “not needed” be enough on its own?
Show what happens
Whether it is needed here and why, whether it is in place, and if it is left out, the reason.
The Statement of Applicability (SoA) is the document in which the organisation goes through the controls and writes down, for each one, three things: is it needed here and why, is it in place, and if it is left out, why.
Worked control decision
The fictional school has decided which controls its risks call for, and now compares them with Annex A. Three rows of its Statement of Applicability look like this. (The control names are shortened.)
| Control | Needed here? Why? | Implemented? |
|---|---|---|
| Access rights: reviewing who has access | Yes. Staff change role and leave, and permissions outlast the need for them, as Mr Osei’s did. | Partly. Reviews are designed and approved. The first one is next half term. |
| Backing up information | Yes. Losing pupil records would stop the school working. | Yes. Nightly backups; a restore was last tested in June. |
| Secure software development | No. The school writes no software of its own; it buys every system it uses. | Not applicable. |
Check your understanding
Show the answer
Answer: A. Needed; partly implemented.
That it is needed and only partly implemented. Claiming it is in place would be false, and leaving it out would be worse.
Three lessons are in those three rows.
- “Needed” and “implemented” are separate columns, and both must be truthful. The access review is needed and not yet running. Writing “Yes” in the last column because a policy has been drafted would be false. Leaving the row out because the work is unfinished would be worse: a control that is needed does not stop being needed by being left off the list.
- An exclusion needs a real reason. “The school writes no software” is one. “It is inconvenient” or “we have not got round to it” is not.
- “Implemented” is not “working”. The table says backups are in place. Only the restore test in June is evidence that they work.
The Statement of Applicability is therefore a record of decisions. It is not a list of every imaginable control, it does not replace assessing risk, and it does not prove that any listed control is effective. An organisation may also need controls that are not in Annex A at all. The ISO/IEC auditing practices note on the SoA explains the relationship; the standard itself remains the source of the requirements.
A quick test of any security document is to hand it to the person who has to follow it. If they cannot tell what is required of them, who to ask and where the current version lives, the document needs work, however well written it is.
Stage: Apply
Apply it in a new situation
These questions use the lesson in situations it has not shown. For the strongest test of your understanding, come back to them on another day and answer each one at the first attempt.
Apply it
Apply it
Show the answer
Answer: C. That is no real reason.
Inconvenience is not a justification. An exclusion needs a real reason, such as the control not applying to the organisation’s activities.
Apply it
Show the answer
Answer: A. Whether it is clear and usable.
Whether the procedure is clear and workable for the people who must follow it, and whether they were helped to understand it. A tick shows only acknowledgement.
Stage: Check
Check your understanding
These questions come from the approved revision bank. Choose an answer and check it; the explanation and its sources follow.
Show answer
Answer: Procedure
Procedures explain the steps. Policies set rules, standards specify requirements and guidelines provide recommendations.
Revision sources: Session 2: Cyber Fundamentals Part 2 (Classroom session record)
Show answer
Answer: Policy states organisational intent and responsibilities.; A procedure explains the authorised steps to request and remove access.; Approval records and actual permission checks help show implementation.
Policy sets direction; procedure guides execution; records and checks support evidence. A written requirement or closed ticket alone cannot prove the real permissions match intended access.
Revision sources: Session 3: Governance, Risk and Compliance (Classroom session record) · Session 4: Governance, Risk and Compliance — In Depth (Classroom session record) · Security Documentation (Supplementary Study Guide explanation)
Show answer
Answer: Include the necessary control with its rationale and truthful implementation status.
The SoA records necessary controls, inclusion rationale, status and justified Annex A exclusions. A needed control is not made unnecessary by being unfinished; evidence is still needed to establish effectiveness.
Revision sources: Session 3: Governance, Risk and Compliance (Classroom session record) · Session 4: Governance, Risk and Compliance — In Depth (Classroom session record) · Security Documentation (Supplementary Study Guide explanation)
Study and revision
Use the Governance & Policy topic for available revision and its stated scope. Revisit GRC for decision ownership and Risk for assessment and treatment.
Stage: Consolidate
What to remember
- A policy states intent and responsibility; a standard, what must be true; a procedure, the steps; a guideline, advice.
- A document says what should happen; a record shows what did.
- A closed request is evidence that an action was reported, not proof that the result is right: checks show that.
- Controlled documents have an owner, audience, current version, approval and review date, and go round a lifecycle.
- A Statement of Applicability records which controls are needed, whether they are in place, and why any are excluded; it does not prove they work.
Key terms
- Policy
A document that sets organisational rules and expectations, defining what is and is not permitted.
- Standard
A document that specifies requirements or recognised practices to be met.
- Procedure
Step-by-step instructions explaining how a particular task should be carried out.
- Guideline
Recommended practice that helps people make appropriate decisions where rules do not cover every situation.
- Statement of Applicability (SoA)
The document, required by ISO/IEC 27001, in which an organisation lists the security controls it needs, why each is included, whether it is in place, and its reason for leaving out any control in the standard’s reference list (Annex A).
Common misunderstandings
A policy sets intent and expectations. Procedures give the steps; standards give the mandatory specifics.
A document states what should happen. Records and checks show whether it does.
It records which controls are needed and their implementation status. Effectiveness needs separate evidence.
Lesson sources and acknowledgements
Sources and scope
This lesson develops the foundations recorded in Session 2 and the approved Session 3 and Session 4 Learning Logs. The access-management walkthrough is a fictional educational extension, not evidence of procedures or an ISMS I have implemented.
- Taught in Session 2 (see the Session 2 Learning Log): policies, standards, procedures and guidelines as security documentation.
- Taught in Sessions 3 and 4 (see Session 3 and Session 4): the Statement of Applicability within ISO/IEC 27001; policies needing communication, training and enforcement rather than acknowledgement alone.
- Supplementary explanation: the school-trip comparison, the pyramid diagram, the access-management walkthrough, keeping documents useful, decision records, the one-sentence introductions to ISO/IEC 27001, the ISMS and Annex A, the worked SoA decision and its three-row extract, the documentation lifecycle diagram, the practical note and the misunderstandings.
- Fictional material: the school, Mr Osei’s role change and the Statement of Applicability rows are invented. They supply no real staff records, measured outcomes or completed assessment, and the control names in the extract are shortened descriptions, not quotations from the standard.
- Guided version (published 1 November 2026, awaiting the site owner’s editorial review): the school-trip opening questions, every question asked in the lesson with its feedback and hints, the application questions and the closing summary are supplementary explanation written for the Study Guide. The settings are fictional. The questions in the lesson’s steps are not revision-bank items; those in “Check your understanding” are, unchanged.
- No practical work is claimed. I have not written or maintained an organisation’s security documentation.
The list of reference security controls at the back of ISO/IEC 27001. An organisation compares the controls it has chosen against the list and records, for each one, whether it applies and why.
A measure intended to modify risk, for example by restricting access, detecting misuse or supporting recovery.
Recommended practice that helps people make appropriate decisions where rules do not cover every situation.
Protecting information by bringing together policies, processes and technical controls throughout the information’s lifecycle.
A scoped management system of policies, processes, controls and review through which an organisation manages information security.
The international standard specifying requirements for an ISMS within a defined scope. Organisations can be certified against it.
Authentication that requires two or more different types of factor, such as something you know and something you have.
A document that sets organisational rules and expectations, defining what is and is not permitted.
Step-by-step instructions explaining how a particular task should be carried out.
Uncertainty and potential harm to an organisation’s objectives, considering what could happen, how likely it is, the consequences and the organisation’s context.
The document, required by ISO/IEC 27001, in which an organisation lists the security controls it needs, why each is included, whether it is in place, and its reason for leaving out any control in the standard’s reference list (Annex A).
A document that specifies requirements or recognised practices to be met.
Your progress on this lesson
Saved in this browser only. It is not sent anywhere, does not follow you to another device, and is lost if you clear this site’s data.
This browser is not allowing the site to save progress, so it will be forgotten when you leave the page.