0.1 What This Course Is

Introduction

This course teaches you to build and run an organization's security governance, risk and compliance program. It starts from a blank page: who decides what, the program's structure, policy, risk, certification, frameworks, obligations, suppliers, audit, and reporting. By the end, each part has been taught, worked through on examples from different organizations, and practiced on an organization of your own.

The course is the entry course of Ridgeline's GRC path. It assumes no previous GRC experience. Every term is explained when it first appears, and every method is shown working before you are asked to use it.

This lesson covers what a GRC program is, how people arrive at GRC work, what the frameworks leave to you, who the course is for, what it covers, what it does not teach, the courses beside it, what you will build, time and pace, and how the course fits any organization.

The course uses the term "GRC program" in a specific sense. The definition below sets it out.

Governance decides direction and accountability: what the program is for, who is accountable for security risk, how much risk the organization will accept, and what its policies require. Risk management decides which risks matter and what to do about each: reduce, accept, avoid or transfer it. Compliance shows the organization meets what it must, from laws, contracts and standards it has chosen or been given.

The three are held as one program by named people, recorded so that someone else can check them, and run year after year. That last part is easy to forget. A program built once and then left is a set of documents; a program run is a set of decisions that keep being taken as the organization, its risks and its obligations change.

The definition's note makes the point the whole course rests on. Governance, risk management and compliance are decisions, and each decision leaves a record. A risk acceptance is a decision recorded in the risk register with the name of the person who took it.

A policy is a governance decision recorded in an approved document. A compliance claim is a decision that a requirement is met, recorded with the evidence that shows it. When an auditor, a regulator, a customer or a board asks how the organization manages security, the answer is those records.

Lesson 1.1 separates the three decisions in detail, with who holds each and the records each produces. CSF 2.0, the framework the course builds the program on, puts governance at its center for the same reason: the other functions of a security program follow from the decisions governance takes.

The course's subject is the program, not any one framework. Frameworks are tools the program uses, and the course teaches several of them, but its aim is that you can build and run a program that stands up whichever frameworks your organization needs.

Most people do not set out to work in GRC. The cards show four common routes in.

An analyst from security operations, who knows the controls well, is asked to own the framework the company has just committed to. An IT lead is handed an audit request list and a certification deadline.

An auditor moves to the other side of the table and must build what they used to test. And sometimes someone is told the company needs a SOC 2 report by spring, and that it is now their job.

Each route brings strengths and gaps. People from security operations understand controls and threats but may never have written a policy or rated a risk on a scale others will use. People from IT know systems and change but may not know what an obligation register is for.

Auditors know what evidence holds but may never have built the program that produces it. And people who arrive from nowhere in particular often have the hardest start, with a deadline and no map.

The course is written for all four. It explains every concept at first use, so nobody is assumed to know the vocabulary. It also does not stop at definitions, so people who know parts of the subject find the judgment they are missing.

What all four routes share is the moment of being handed a framework and a deadline. A framework is a useful thing to be handed: it says what a program should achieve. It rarely says how to decide, for a particular organization, how much is enough. The next section is about that gap.

If you recognize yourself in one of these routes, the practice in lesson 0.4 suggests where to begin: with the program artifact you most need first, whether that is a risk register, a policy set or an evidence map.

Frameworks describe outcomes. They leave the organization to decide how to reach them. The tiles name six decisions every program faces that no framework settles.

How much policy is enough: enough to direct people, not so much that nobody reads it. How to rate a risk so that two people rate it the same. Which controls apply, and how to justify each choice.

How one control can satisfy four frameworks at once, mapped once and evidenced once. What an auditor will ask for, and what evidence holds up. And what to tell a board about where the program stands, and what to ask it to decide.

Each of these is a judgment. A framework can say that risks should be assessed and prioritized; it cannot say whether a particular phishing risk at a particular company is high or medium.

A standard can require a Statement of Applicability; it cannot say which controls a 200-person software company should exclude. Those answers depend on the organization, and the course's job is to teach how to reach them in a way someone else can follow and check.

The course teaches judgment the same way throughout. It shows the decision, the facts it turns on, the record it produces, and the reasoning. Then it shows how the answer changes when the facts change: a larger organization, a regulated sector, a different appetite. Then it asks you to take the decision yourself, in the practice.

That is also why the course spends time on things frameworks treat briefly: calibrating raters so their scores agree, writing a policy someone will follow, writing a finding's cause, setting a risk indicator's thresholds. These are where programs succeed or fail in practice. A program with a perfect framework mapping and raters who disagree by two levels on every risk will make poor decisions however good its documents look.

The course is written for four kinds of reader. The cards set them out.

Security analysts, engineers and IT staff moving into GRC: people who know security and need the governance, risk and compliance method. New GRC, risk and compliance analysts in their first year or two: people in the role who want to understand why the work is done the way it is, and how to do it better.

Security managers who now own a certification, a framework or an audit: people with responsibility who need to know what good looks like. And consultants who help clients build and run programs: people who need a method that works across many organizations.

The course assumes no minimum experience. It does assume you are willing to do the practice, because the course is built so that understanding comes from building the artifacts, not only reading about them.

It is not written for two groups. Lawyers looking for legal analysis will find laws treated as obligations to record and map, cited by article and paraphrased, with interpretation left to counsel. And candidates who want a cram course for CISSP, CISM, CRISC or an ISO/IEC 27001 lead implementer or lead auditor certificate will find that the course teaches the judgment those exams assume rather than drilling their questions.

Many students take the course alongside such a certification and find it fills the practical gaps the exam syllabus leaves.

If you are not sure whether the course is for you, lesson 0.5 suggests a quick test: read lesson 1.1 and do its practice. If the practice is useful to you, the rest of the course will be.

The course also suits teams. A security team moving into GRC can take it together, each person building their part of the program file and the team reviewing each other's work against the checks lesson 0.4 describes.

The course covers a program from foundation to running. The figure shows its 11 teaching modules in order.

Modules 1 to 3 build the foundations: the charter and roles, the program's structure on NIST CSF 2.0, and the policy framework. Modules 4 and 5 cover risk: assessment with NIST SP 800-30 Rev. 1 and the risk register with NIST IR 8286 Rev. 1.

Modules 6 to 8 cover frameworks and obligations: certification to ISO/IEC 27001, mapping one control set to many frameworks, and compliance obligations including SOC 2 and privacy law. Modules 9 to 11 cover running the program: supplier risk, audit readiness, and metrics, reporting and running the program as a cycle.

The order matters. Each module builds on the records the earlier ones produced. Risk assessment in Module 4 uses the scope and asset owners from Module 2. The risk register in Module 5 feeds the Statement of Applicability in Module 6.

The control mapping in Module 7 is what Module 8's obligations land on. Supplier risks in Module 9 go into Module 5's register. Audit readiness in Module 10 tests the controls everything before it selected. And Module 11 runs the whole thing on a calendar and reports it.

There are 97 teaching lessons across the 11 modules. Lesson 0.2 describes how each module and lesson is built.

The course does not have to be read straight through. A reader who already has a program can go to the module they need, and each lesson names the earlier lessons it depends on. A reader starting from nothing should read in order. Either way, the module index pages describe each lesson in a line, so you can see what a module holds before opening it.

The course also covers the work around the program that frameworks treat lightly: calibrating risk raters, writing exceptions with expiry dates, reading a supplier's assurance report as a buyer, answering an auditor's population request, and writing a board paper someone can decide from.

The course stops at four boundaries. The comparison sets them out.

Law is taught as obligations to record and map, cited by article and paraphrased. Legal advice and interpretation belong to counsel. Every lesson that touches law says so, and the program's job, as Module 8 teaches, is to record counsel's interpretation as the requirement and map it to controls.

Controls are taught as decisions: which to select, why, and how to show they work. Configuring them in a particular product belongs to the courses and documentation for that product. The course stays product-neutral, so its method holds whatever tools your organization uses.

Standards are taught from NIST, whose publications are free to read and may be quoted. ISO/IEC 27001 is taught at the level of its clauses and the themes of its Annex A, described in the course's own words; the ISO standards are paid documents, and their text is never reproduced. You read the controls themselves in your organization's copy.

Certifications are a different goal. The course teaches the judgment that CISSP, CISM, CRISC and ISO lead roles assume, not the exam questions.

The boundaries are deliberate. Each keeps the course honest about what it can teach well. A course that gave legal advice would be wrong somewhere in the world on any given day; one tied to a product would date when the product changed; one that reproduced ISO text would break the standard's copyright.

Staying inside the boundaries lets the course be accurate everywhere it teaches. Where a lesson reaches a boundary, it says so and says who to ask, so you know when you have reached the edge of what the program decides, and the program's record shows who took the decision on the other side.

Lesson 0.3 sets out exactly which versions of which frameworks the course relies on, and where to read each.

This course is complete in itself. Some of its subjects are taught further in other courses. The cards set them out.

GRC301 Security Control Assessment and Assurance takes the assessor's side of the same controls. Module 10 of this course teaches the program owner to test its own controls and support an audit; GRC301 goes further on test design, sampling and determinations, from the assessor's chair.

GRC302 AI Governance and Risk Management governs one class of system, AI, using the same method this course teaches for security. Module 11 of this course treats AI law as a source of regulatory change; GRC302 goes much further into AI systems, their risks and the standards written for them.

ARC501 Microsoft 365 Security Architecture and ARC502 Entra ID Identity and Access Management implement, in specific products, many of the controls this course selects. Neither is assumed: this course is product-neutral, and its method works the same whatever products carry the controls.

The GRC path runs in that order for most people: this course first, as the program owner's course, then GRC301 for those who will assess controls, and GRC302 for those who will govern AI. Each is complete on its own, and where a subject is needed in more than one, each teaches it in full rather than sending you elsewhere.

You do not need any of the others to take this one. If you finish this course and want to go deeper, the most common next step is GRC301, because the controls this course selects are the ones GRC301 teaches you to assess.

Readers who will govern AI systems often go to GRC302 next instead, because its method will already be familiar. Readers implementing controls in Microsoft environments go to ARC501 or ARC502. The order is a suggestion; each course stands alone.

Each lesson's practice produces a program artifact. Together they make a program file. The record below lists what it holds by the end.

Governance: the charter, roles and decision rights, and the policy set with its exception process. The program: context, scope, asset owners, a CSF profile and a roadmap. Risk: a risk assessment and a risk register with treatments and acceptances. Certification: an ISMS scope and Statement of Applicability lines.

Compliance: a control mapping, an obligation register and a notification matrix. Suppliers and audit: a supplier inventory and assessment, an evidence map, self-tests and a remediation plan. Running it: a program calendar, metrics, risk indicators, and management and board reports.

The note under the record says why this matters. Every item is a real program artifact. Built for your own organization, the file is a working program by the end of the course. Built for the fallback scenario, it is a complete worked set you can adapt when you need one.

Lesson 0.4 explains how the practice works, how to choose between your organization and the scenario, and how to check your own work. Each module also ends with an exercise lesson that builds a module's worth of artifacts at once for one organization, so you see them working together.

The file grows unevenly. Early modules add a few documents each; Modules 4, 5 and 8 add large registers; Modules 10 and 11 mostly use what is already there. That is how a real program grows too: the foundations take thought, the registers take time, and running the program takes discipline.

By the end, every artifact in the file can be traced to the lesson that taught it, so when one needs revisiting, you know where to look. The file is also what you would hand to a successor, or show an auditor, as the program's working record.

The course takes most people 36 to 40 hours. The tiles break that down.

A lesson takes about 25 to 35 minutes to read, plus its practice, which varies from a few minutes to an hour depending on whether you are working on your own organization and how much you already have. A module takes about a week at three or four lessons a week. The course carries 40 CPE on completion.

The pace that works best is steady rather than fast. GRC practice improves with a little time between lessons: a policy drafted on Monday reads differently on Thursday, and a risk rating that seemed obvious looks less so after a conversation with its owner.

Students who do one or two lessons a sitting, with their practice, finish with a better program file than those who read a module in a day.

The exercise lessons at the end of each module take longer than others, because they build a whole module's artifacts for one organization. Allow an hour or two for each.

If you are using the course to build your organization's program for real, its pace will be set by your organization rather than by the course. A risk assessment takes as long as the conversations with risk owners take. The course is designed so that you can pause after any lesson, do the work in your organization, and come back.

The course exam, described in lesson 0.5, comes at the end. It takes 90 minutes. You do not need to review the whole course before it: the program file you built while studying is the best revision, because the exam asks for the same judgments the practice did. If you pause the course for weeks, rereading your last module's exercise lesson is the quickest way back in.

The course teaches methods that hold for any organization. The gate shows how a lesson applies to yours.

If the method is the same for any organization and the examples show it at one size, follow the lesson as taught.

If your size or maturity calls for a proportionate version, use the lesson's closing section on size: every teaching module ends each lesson with what changes when the organization is smaller, larger, regulated or part of a group. If your sector or location adds requirements, record them with Module 8's method as obligations mapped to the same control set.

The gate's foot states the principle. There is no "does not apply". The course's methods hold for a bank, a hospital, a software company or a 50-person firm. What changes is how much structure each needs, and which obligations arrive on top.

That is also why the course has no case company. A case company makes every lesson about one organization's size, sector and history, and the reader has to translate.

Instead, each lesson uses its own short examples from a different kind of organization: a payroll company, a water utility, a law firm, a credit union, a university. No example recurs, and no lesson depends on another lesson's example, so you can read any lesson on its own.

The examples are chosen to show the method under different conditions. A risk register example from a hospital shows why patient safety changes impact ratings; a supplier example from a software company shows why cloud subservice organizations matter.

Seeing the method in many settings is the best preparation for applying it to yours. When a lesson's example is far from your organization, the closing section on size usually shows a version nearer to it, and the practice always applies to your own.

A GRC program is three kinds of decision, governance, risk management and compliance, held by named people, recorded and run year after year.

This course teaches the judgment frameworks leave to the organization, for readers moving into GRC from any route, across 11 modules in the order a program is built. It leaves legal advice, product configuration and ISO text to others, and builds a program file through its practice, for your own organization or a fallback scenario.

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).