0.2 How the Course Is Built

Introduction

Lesson 0.1 set out what the course teaches. This lesson shows how it is put together: the phases and modules, what a module index page holds, the anatomy every lesson follows, how sections teach, the aids you will meet, why each lesson uses its own example, the exercise lessons, how lessons point to each other, and where to start.

Knowing the structure saves time. Every lesson in Modules 1 to 11 is built the same way, so once you know where a lesson keeps its practice, its summary and its versions line, you can find them in any lesson without searching. Every module index page is built the same way too.

This lesson covers the phases, the modules, module index pages, lesson anatomy, sections, aids, worked examples, exercises, cross-references, and reading paths.

The course's 11 teaching modules fall into four phases. The tiles show them, with the lesson count in each, read from the course's own files.

Foundations come first: the operating model and charter, the program's structure on NIST CSF 2.0, and the policy framework. A program that starts anywhere else ends up rebuilding these later, because every later record depends on who decides and what the program is for.

Risk comes second: assessment and treatment. Risk is where the program decides what matters, and everything after it, from controls to suppliers to reporting, is sized by it.

Frameworks and obligations come third: certification to ISO/IEC 27001, mapping one control set to many frameworks, and compliance obligations. These take the program built in the first two phases and show it meets what it must, without building a separate program for each framework.

Running the program comes last: supplier risk, audit readiness, and metrics, reporting and the calendar that keeps the program going year after year.

The phases are also a way to plan your time. Foundations and risk together are a little under half the course, and they are the parts most programs rush. A reader who takes the first two phases slowly finds the third and fourth faster, because the records they need already exist.

The phases match how a program is usually built in practice, though in practice they overlap: an organization facing an audit next month starts Module 10's work while the risk register is still being built. The course teaches them in order so that each is explained before it is used; your program can work on several at once.

The phase a lesson belongs to is shown by its module number, and the color each phase uses in the course's figures matches the tiles above: navy for foundations, brick for risk, ochre for frameworks and obligations, green for running the program.

The figure shows the 11 modules and how many lessons each has.

Each module has between 8 and 10 lessons. The number is set by what the subject needs, not by a template. Risk assessment and compliance obligations have the most, because each has several distinct methods to teach. Modules with fewer lessons are not lighter; their subjects divide into fewer parts.

Module 1 covers GRC foundations and the operating model: what governance, risk and compliance each decide, the three lines, roles, where GRC sits, why programs fail, and the frameworks. Module 2 builds the program on CSF 2.0: context, scope, assets and owners, classification, a baseline, maturity, a roadmap and the program's records.

Module 3 is the policy framework. Module 4 is risk assessment with SP 800-30 Rev. 1. Module 5 is risk treatment and the register with IR 8286 Rev. 1. Module 6 takes the program to ISO/IEC 27001:2022 certification. Module 7 maps one control set to many frameworks.

Module 8 covers compliance obligations: SOC 2, privacy law with GDPR as the reference, breach notification, and contractual and sector requirements. Module 9 is third-party risk. Module 10 is audit readiness. Module 11 is metrics, reporting and running the program.

The lesson counts come from the course's own files, so they match the course as it stands. There are 97 teaching lessons in all, plus the five of this orientation module.

The sizes are a guide to time as much as to content. At three or four lessons a week, a ten-lesson module takes about three weeks and an eight-lesson module a little over two. The modules are listed in the figure in course order, so the bars also show where the heavier stretches fall.

Each module's index page lists its lessons in a line each, so you can see a module's shape before you open it. The next section shows what else the index page holds.

Every module begins with an index page. The record below sets out what each one holds.

The introduction says what the module covers and why it sits where it does in the course. The figure shows the module's subject in one picture. The lesson map lists each lesson in a line with its kind.

The section on getting the most from the module says what to read first and which earlier records to have to hand. The section on what you will be able to do lists the capabilities the module builds. And the start-here section names the first lesson to open.

The note under the record explains the kinds. A concept lesson explains something you need to understand before deciding anything: what an obligation is, how a SOC 2 report is structured. A judgment lesson teaches a decision: how to tier a supplier, how to rate a risk, how to set a threshold. A worked case runs the whole module on one organization: the exercise lesson that closes each module.

The index page is worth reading even if you go straight to a particular lesson.

The "how to get the most from this module" section often names records from earlier modules that the lessons assume you have: Module 9's index, for example, asks you to have the risk register of Module 5 and the obligation register of Module 8 to hand, because supplier risks go into the first and supplier contract terms into the second.

Index pages are also the quickest way to review.

Reading the eleven index pages takes about half an hour and gives a complete picture of the course, which is useful before the exam or when deciding where to go back to. It also helps to return to an index page after finishing its module, to check that they can now do each thing its "what you will be able to do" section lists.

Every lesson in Modules 1 to 11 has the same anatomy. The definition below lists its parts.

An introduction says what the lesson covers and names the worked example it uses: an organization, its size and what it does. Ten numbered sections each teach one part of the subject.

A practice card sets a program artifact to build, with a fallback scenario if you have no organization of your own. A closing summary restates the lesson in one paragraph. And a versions line at the foot lists every framework, standard and law the lesson relies on, with its version.

The note under the definition gives the reason. The anatomy never changes, so you always know where to find the practice and the versions.

The ten sections are the lesson's body. Each has a numbered heading and a short subtitle that says what it settles, so scanning the headings tells you the lesson's argument. The last section of every lesson in Modules 2 to 11 covers the subject at any size: what changes for a small organization, a regulated one or a group.

The closing summary is useful in two ways. Before reading, it tells you what the lesson will conclude. After reading, it is what you should be able to say in your own words. If you cannot, the section headings point you to the part to reread. Reading the summary and the section headings of a lesson you finished weeks ago is usually enough to bring it back.

The anatomy is the same in this orientation module's lessons, apart from the closing section on size, which these lessons do not need. The versions line is the course's commitment to accuracy. Frameworks change, and a lesson that cites one without its version cannot be checked. The course's own checks refuse any lesson that names a framework without its version, as lesson 0.3 explains.

Each section teaches in prose and uses an aid where the aid does something the prose cannot. The comparison shows the difference between an aid that works and one that only decorates.

Text in a box restates a paragraph inside a colored panel. It adds nothing the prose did not say, and you read it twice. The course avoids it.

An aid that works shows the record a decision produces, or the decision itself as a gate, or a draft checked line by line. It adds the artifact, the steps or the test, at the point the prose needs it.

And it gives you something to copy: the shape of a register entry, the questions of an evaluator, the branches of a gate, which you then use in your own program.

Every section opens with prose that sets up the aid and closes with prose that draws its consequence. The aid sits between them. That order is deliberate: the prose tells you what to look for before you see the aid, and what it means after. A section that ended on an aid would leave you to work out the point yourself.

Most sections carry one aid. A section working an example in detail may carry two or three. Lessons average roughly one aid for every few hundred words of prose, which is enough to show the artifacts and not so many that the lesson becomes a gallery.

The aids are drawn in a style meant to look like the documents GRC work actually produces: register entries on paper, decision trees, timelines, heat maps. When you build your own program, you can copy their layout directly. Copying the fields of the course's register entries into a spreadsheet is a sound way to build a first risk register: the fields were chosen to be the ones a register needs.

The course uses a set of aids built for GRC work. The cards show the five you will meet most often.

Register entries are the course's main instrument. A GRC program is largely a set of registers, risk, policy, obligation, supplier, exception, findings, and each entry records a decision, the facts it turns on and who owns it. Seeing many register entries teaches what a complete one looks like.

Gates set out a question with its possible answers and what follows each. They are decisions written down before they are needed, which is how a program makes the same decision the same way twice.

Evaluators take a real request or draft and check it line by line, with each check passed, failed or noted, and a verdict. They teach you to read a document as a reviewer would.

Diffs show a document before and after a change, with the reason for each line that moved. They teach revision: why a policy, contract or report changed, and what the change achieved.

Figures are the diagrams GRC practitioners draw: heat maps of risk, crosswalks between frameworks, program calendars, audit timelines, indicator charts against tolerance. Wherever a figure shows a count or a measure, the number is computed by the script that drew it, so the figure and the prose agree.

You will also meet versus comparisons, which put two approaches side by side; token cards, which show who may decide what; sinks, which show where a decision lands and who reads it; and mistake boxes, which show a common failure and the fix.

Every aid type appears often enough that by Module 3 you will read them without thinking about the format. The predict blocks are the exception: they ask you to commit to an answer before the lesson reveals it, so read the question and decide before opening the reveal.

The course has no case company. The transform shows what that changes.

A case company would carry one fictional organization through the whole course. Every lesson would depend on its history, its size, sector and country would frame every answer, and you would translate each lesson to your own organization. Lesson 7 would need lessons 1 to 6 to make sense.

This course uses a different organization in each lesson instead: a credit union, a law firm, a water utility, a staffing company, a hotel group. Each worked example sits inside its lesson and does not recur. The method is shown under different conditions of size, sector and location. And any lesson can be read on its own, with earlier lessons named where they are needed.

The choice has a cost: you do not watch one organization's program grow from nothing to maturity. The exercise lessons make up for it, because each runs a whole module's method on one organization, and the program file you build in the practice is the one program that grows through the whole course.

The examples are written to be realistic, not dramatic. The organizations have ordinary sizes, ordinary problems and ordinary constraints: a vendor that sends its report late, a manager who leaves, a budget that covers half of what is needed. Where a lesson's example contains numbers, the numbers are computed from the example's own data, so they agree everywhere they appear.

No example uses a real company's name or represents a real organization. Where a lesson refers to real publications, standards bodies or regulators, it cites them by name and date, and the versions line lists them. When a lesson's example is close to your own organization, it is a coincidence; when it is far, the closing section on size helps translate it.

The last lesson of each module is an exercise. The cards list them.

Each exercise takes one organization through the whole module's method: a charter built from nothing, a baseline and roadmap, a policy set, a risk assessment, a register, an ISMS scope and Statement of Applicability, a control mapping, an obligation register, a supplier assessment, an audit period, and a year's program report.

Every count in an exercise is computed from the example's own records, so you can follow the numbers from one section to the next.

Exercises take longer than other lessons: allow an hour or two each. They are the best place to check your judgment, because they show many decisions together and how they depend on each other. A supplier tier decided in one section sets the assessment depth in the next, and the contract terms after that.

Reading an exercise slowly, asking at each section why the decision went the way it did, is one of the best uses of time in the course, and the surest way to see how the module's lessons fit together.

The exercises also show a complete set of artifacts, which helps when you build your own. If your program file's obligation register looks thin, the Module 8 exercise shows what a complete one for a comparable organization contains.

Each exercise ends with a practice card that asks you to do the same thing for your organization, or for the fallback scenario. Doing an exercise's practice is the closest thing in the course to building a module's worth of your program in one sitting.

If time is short, the exercises are also the lessons to prioritize when revising for the exam, alongside the module index pages. The exam's case studies ask for the same kind of connected judgment the exercises show: several decisions about one organization, each depending on the last.

Lessons often refer to each other. The tiles show how.

"Lesson 5.6" means module 5, lesson 6: the exact lesson, which you can open from the module index. "Module 8's method" means the method that module teaches, without naming a single lesson. "As lesson 10.3 described" means the current lesson reuses a rule that lesson set out, so you can go back to it for the reasoning.

No lesson uses "later" to promise content in another lesson. Every lesson is complete on its own subject, and where a subject is needed but taught elsewhere, the lesson names where. That rule keeps lessons honest: a lesson cannot defer the hard part to a future one that never quite delivers it.

Cross-references run in both directions. Earlier lessons sometimes point forward to where a subject is built in full, such as the risk register lesson naming Module 11 as where key risk indicators are developed, but they never leave their own subject incomplete.

Later lessons point back to the rules they reuse, which is how the course stays consistent: the authority table set in lesson 5.6 is the one every later lesson refers to when someone accepts a risk.

The references make the course a reference work as well as a course. Once you have finished it, you can return to a single lesson, follow its references back to the rules it depends on, and reconstruct the reasoning without rereading everything.

When a reference names a lesson you have not read, you do not need to stop. The current lesson tells you enough to continue, and the reference is there if you want the full reasoning.

Following references is also a good way to review: start from an exercise lesson and follow every lesson it names, and you will have reread the core of that module in the order its method uses it.

Different readers should start in different places. The gate sets out three paths.

If you are new to GRC or building a program from nothing, start at lesson 1.1 and read in order. If you run a program and need one part, start at the module you need: read its index, then its lessons in order.

If you know the subject and want to check your judgment, start at the exercise lessons, then read any lesson an exercise names, in the order the exercise uses them.

The gate's foot says that every path ends the same way: with your own program file. Lesson 0.5 helps you choose a path.

The second path is the most common for experienced readers. A security manager facing an ISO certification audit in three months might start with Module 6, then Module 10, and come back to Modules 4 and 5 when the Statement of Applicability needs a risk assessment behind it. The cross-references make that possible: each lesson says what it depends on.

The third path suits consultants and experienced practitioners, and anyone short of time who want to see where their own practice differs from the course's. The exercises show the method as a whole, and the differences are usually in the details: how risks are calibrated, how findings' causes are written, how indicators are thresholded.

Whichever path you take, do the practice. The course is built so that understanding comes from building the artifacts, and the program file, which lesson 0.4 sets up, is the one thing that grows through the whole course whichever path you take through it.

You can also change path partway: a reader who starts at the module they need may find they want the foundations behind it, and go back to Module 1 with a clearer idea of why it matters.

The course runs in four phases across 11 modules sized by their subjects. Each module opens with an index page and closes with an exercise, and every lesson has the same anatomy: an introduction, ten sections that teach in prose with aids where they work, a practice card, a summary and a versions line.

Each lesson uses its own example organization, lessons point to each other by number, and you can read in order, start at the module you need, or start at the exercises.

Versions this lesson relies on: NIST SP 800-30 Rev. 1 (September 2012); NIST IR 8286 Rev. 1 (18 December 2025); ISO/IEC 27001:2022 with Amd 1:2024; NIST CSF 2.0, NIST CSWP 29 (26 February 2024); AICPA 2017 Trust Services Criteria, revised points of focus (2022); GDPR, Regulation (EU) 2016/679.