The document hierarchy that governs everything you will later encode, and how to keep it from rotting.
25 min 150 XPSkills: Governance, Policy
Brief
Before you can encode a control you have to know which document it lives in, who approved it, and what happens when it changes. The governance document hierarchy is the boring part of GRC that quietly determines whether your automation is authoritative or just a script someone wrote.
Policy says why and who. Standard says what, exactly. Procedure says how, step by step.
The hierarchy
A policy is a short, high-level statement of management intent, approved at the most senior level. It says the organisation will protect data in transit: it does not say TLS 1.2. Policies change rarely and every exception is escalated.
A standard is the mandatory, measurable requirement that makes the policy testable: minimum TLS 1.2, keys of at least 2048 bits, quarterly access reviews. Standards are where automation attaches, because a standard is already close to an assertion.
A procedure is the step-by-step instruction a human or a pipeline follows to satisfy the standard. Guidelines sit beside all three and are advisory only: recommended, never mandatory, never audited as a failure.
Policy, standard, procedure, and guidelines beside the stack, never inside it.
Why engineers care
When you write a Rego rule or an evidence job, you are implementing a standard. If the standard is vague, the automation becomes the de facto standard, and nobody approved it. The first act of GRC engineering on any control is often just forcing the standard to be specific enough to test.
Traceability matters too: a control check should reference the standard, which references the policy, which references the framework requirement. That chain is what makes an automated result usable as audit evidence.
One intent, traced down to the artifact the auditor actually opens.
Keeping the set alive
Governance documents rot. The standard review cadence in most frameworks is at least annually, with an out-of-cycle review whenever the environment materially changes. Review means someone with authority re-approves it, not that the date field was edited.
Approval sits with management, not with the author and not with the auditor. An auditor who approves a policy has just made themselves un-independent for the next audit.
Guidelines, exceptions and the words that matter
A fourth document type sits beside the three: the guideline. Guidelines recommend; they use should and may. Policies and standards require; they use must and must not. An auditor tests only what is mandatory, so a control written as a guideline has no requirement behind it.
When someone cannot meet a mandatory standard, the answer is an exception, not silence. A valid exception names the requirement, the reason, the compensating measure, the risk owner who accepts it and an expiry date. An exception with no expiry is a quiet policy change.
Must is a requirement. Should is a suggestion. Auditors only test requirements.
Tasks
Answers are graded on the server: the answer key never reaches your browser.
Task 1: Mislabelled artifacts
Answer challenge+30 XP
Ignore every title. Classify each document by what is inside it.
Incident brief
Three artifacts arrive from the governance drive ahead of an audit.
DOC-A, titled "Password Policy", is four pages of exact requirements: minimum 14 characters, no reuse of the last 12, lockout after 5 failures, rotation on compromise only.
DOC-C, titled "Encryption Standard", is a numbered walkthrough: open the console, select the key ring, click Rotate, paste the ticket ID into the change record, screenshot the confirmation.
The document owner insists the set is fine: "Every title was approved by the committee, so the titles are correct by definition."
Term bank, not all of these are right
policystandardprocedureguidelinebaselinecontrol
1.1By its content, what is DOC-A ("Password Policy") actually? (one word)
1.2By its content, what is DOC-C ("Encryption Standard") actually? (one word)
Task 2: The untestable clause
Answer challenge+40 XP
The clause is not wrong. It is in the right place and missing a neighbour.
Incident brief
You are asked to automate a control for the clause: "Customer data will be protected appropriately in transit and at rest." It is signed by the CEO and sits in a two-page document of management intent.
Your first Rego rule decides that "appropriately" means TLS 1.2 and AES-256, and it starts failing services. A team objects: "Nobody approved those numbers, you invented them: your script is now the rule."
A separate document in the drive, marked advisory, does recommend TLS 1.2. An auditor has never raised a failure against it and never will.
Term bank, not all of these are right
policystandardprocedureguidelinecontrolbaseline
2.1Which document type does the "protected appropriately" clause correctly belong to? (one word)
2.2Which document type must be authored and approved before your rule is authoritative? (one word)
Task 3: Self-approved and stale
Answer challenge+30 XP
Two things went wrong in one commit. Name the authority and the cadence.
Incident brief
The access-control policy was last approved 18 months ago. Its author, a security analyst, updates two clauses, sets the Last Reviewed field to today, adds their own name in the Approved By field, and republishes.
When challenged they reply: "The external auditor read it last quarter and said nothing, so it is effectively approved. And the date field is current now, so the review requirement is satisfied."
3.1Neither the author nor the auditor may approve this. Who holds the approval authority? (one word)
3.2At 18 months, which minimum review cadence was already missed? (one word)
Task 4: Should, must, may
Answer challenge+50 XP
The verb decides what the document is.
Incident brief
The access document says: "Engineers should use multi-factor sign-in for production where practical." It is filed in the Standards folder and approved by the CISO.
Two teams have never turned it on. When asked, they produce a one-line email from their manager saying "fine for now", sent eighteen months ago.
The audit lead says both teams are fine: "It is in the standards folder, so it is a standard, and they have approval."
Term bank, not all of these are right
policystandardprocedureguidelineexceptionwaiver
4.1What type of document does that sentence actually make it? (one word)
4.2What is the formal, time-limited approval to deviate from a mandatory standard called? (one word)
Labs
75 bonus XP
Hands-on work. You edit the artefact, the server runs the checks: the expectations and the reference solution never reach your browser.
The company has a single three-page "Password Policy" that contains an intent statement, key lengths, click-by-click reset steps and an Okta configuration snippet. Every change to any of those requires the CISO to re-sign the whole document.
Sort the five statements into the layer each belongs to, then say where the standard is actually enforced and how often the policy layer is reviewed.
Statements lifted from the current document
S1 The company protects accounts with authentication
strong enough for the sensitivity of the system.
S2 Passwords are at least 14 characters and MFA is required
for all administrative access.
S3 To reset your password, open the IT portal, choose Reset,
then approve the push notification on your phone.
S4 okta_password_policy: { min_length: 14, mfa_required: true }
S5 Exceptions are granted by the CISO and expire after 90 days.
Layers: policy (intent and authority) | standard (measurable
requirements) | procedure (how a human performs a task)
Systems in play: okta, it-portal, confluence
The governance library has been reorganised by someone who filed by tone of voice: anything that sounded firm went in the policy, anything with numbers went in the standard, anything with steps went in the procedure.
Accept the statements that sit in the right document. Reject the ones that were filed by tone rather than by function, and name where they belong.
Verdicts are accept or reject. Every rejection needs one reason code from: belongs-in-policy | belongs-in-standard | belongs-in-procedure.
Library after the reorganisation
P-1 POLICY: The organisation protects production systems from unauthorised access.
P-2 POLICY: Passwords must be at least 14 characters and rotated every 180 days.
P-3 STANDARD: TLS 1.2 or higher is required on all external endpoints.
P-4 STANDARD: The CISO owns this policy and reviews it annually.
P-5 PROCEDURE: To onboard a vendor, raise a ticket, attach the DPA and await security sign-off.
P-6 PROCEDURE: All staff shall act in the interests of customer confidentiality at all times.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Checks
Every line in the fixture carries a verdict
Accept and reject land on the right lines
Each rejection cites a valid reason code
Next on your path · GRC Fundamentals
Cybersecurity Essentials
Distinguish security objectives, attack mechanisms, and layered controls, then evaluate evidence rather than reassuring labels.
