0.4 Practicing With or Without an Organization of Your Own

Introduction

Every lesson in Modules 1 to 11 ends with a practice: one artifact of a GRC program to build. This lesson explains the two ways to do it, with your own organization or with the fallback scenario in the card, and how to do each well.

Lesson 0.2 described the practice card as part of every lesson's anatomy. This lesson is about using it: when you can use your own organization, what an artifact should not contain, how the fallbacks are written, how to fill their gaps, where to keep what you build, and how to check it.

This lesson covers the practice card, the two routes, permission, what not to record, the fallback scenarios, why they change, filling gaps with assumptions, the program file, checking your work, and pace.

Each lesson ends in a practice card asking for one artifact. The figure shows the two routes from the card to that artifact.

A lesson teaches one method. Its practice card asks for one artifact that uses it: a policy and its exception process, a risk entry with its rating, a treatment decision, a Statement of Applicability line, a framework mapping, an obligation register entry, a supplier assessment, an evidence request answer, or a metric with its threshold.

You build it from your own organization where you can, or from the fallback scenario printed in the card. Either route ends in the same kind of artifact; only what it is built from differs.

There are 97 practice cards in Modules 1 to 11, one per lesson, counted from the course's files. The last lesson of each module is an exercise, 11 in all, which runs the whole module's method on one organization and asks for the module's full set of artifacts.

The card has a fixed shape, shown in the tiles below.

A title names the artifact. Numbered steps say what to do, each opening with a short instruction in bold. Under the steps, a fallback scenario says what to use if you have no organization of your own. And the outcome says what you will have when you finish.

The practice is not optional extra. GRC is a practice discipline: the method only becomes yours when you have applied it to something. A reader who skips the practices finishes the course knowing the vocabulary of a program; one who does them finishes with a program's first records.

The practice cards are also cumulative. The program charter from Module 1, the baseline from Module 2, the policies from Module 3 and the risk register from Modules 4 and 5 are each used by later practices. If you build them on your own organization, by Module 11 you have the records of a working program.

The two routes produce the same kind of artifact from different material. The comparison sets them side by side.

With your own organization, you use its real facts, and you get an artifact your program can adopt. It needs permission, and care with what you record. It goes into your organization's program file.

With the fallback, you use the short scenario in the practice card, and you get practice at the method on a stated case. It needs assumptions where the scenario is silent, written down. It goes into your own study file.

Neither route is second best. The fallback is written so that the method can be practiced in full: each scenario carries the facts its practice needs, and often a complication that makes the judgment real.

The own-organization route gives you something you can use, but your organization may not exercise every part of the method. A company with no suppliers of note gives a thin Module 9. Choose by what you can use, not by which feels more serious.

Most readers will mix the two. You may use your organization for policies and risk, and the fallback for certification or supplier work your organization does not do. That is the expected pattern, and the course is built for it: no practice depends on having used the same route for an earlier one. Decide per practice, not once for the whole course.

If you work in GRC already, the own-organization route will often produce something better than what your program holds now, because each practice follows a method the lesson has just set out. If you do not, the fallbacks give you the same method on organizations you could not otherwise see.

Whichever route you take for a practice, say which at the top of the artifact. A record labeled as practice cannot be mistaken for a decision your organization took.

Using your own organization's facts is the most useful route, and it needs permission. The gate sorts the three cases.

If you hold a GRC or security role, or your manager agrees, and the artifact will stay in approved storage, use your organization: build the artifact on its facts.

If you can describe the organization but not its sensitive detail, use part of it: real structure, invented specifics, and say which is which. If you have no permission, no organization, or the subject is too sensitive to write down, use the fallback scenario in the card.

The gate's foot gives the rule that matters: if you are unsure whether you may record something about your employer, ask before you write it, not after. Your employer's policies on confidential information, acceptable use and personal devices apply to course work as they apply to anything else. Nothing in this course overrides them, and nothing in this lesson is legal advice.

The middle route is often the right one. A risk register entry can use your organization's real departments and systems, so the method is practiced on a structure you know, while its likelihood and impact are invented. Label the invented parts. The artifact then teaches you the method without becoming a record of your organization's real exposures held outside its control.

Permission is easier to get than most readers expect. A manager asked "may I draft our policy exception process as part of a course, and share the draft with you?" is being offered work. The course's practices are framed as artifacts a program needs, so many of them can be offered to your organization as drafts.

If you work for a client rather than an employer, as a consultant does, the same applies with the client's permission and your engagement's confidentiality terms. Use the fallback for anything those terms do not clearly allow.

Some things should not be in a practice artifact even when you have permission to use your organization. The cards list them.

Secrets do not belong in any artifact: passwords, keys, tokens and connection strings. A control can be described fully without them. Personal data you do not need does not belong either: names of customers or staff, where a role or a count will do.

Exploitable detail outside approved storage is a risk in itself: an unpatched system named with its weakness belongs in your organization's records, not a personal notebook. And other people's confidential documents, a supplier's SOC 2 report or a customer's contract terms, should be used only as far as the practice needs.

The test is what would happen if the artifact were lost. A risk register entry that says "a customer database is exposed to the internet through a legacy interface" is useful practice. The same entry naming the server, the interface and the missing patch is a map for an attacker, and should exist only where your organization's own controls protect it.

This is the same discipline a GRC program applies to its own records, as lesson 2.8 taught under access to GRC records. The risk register, the exception log and the audit findings are among the most sensitive documents an organization holds, because together they describe its weaknesses. Treat your practice artifacts with the same care.

Where an artifact needs a sensitive fact to make sense, describe it by kind. "An administrator account without multifactor authentication" teaches the method as well as the account's name would, and is safe if lost.

If you are building on the fallback, none of this arises: the scenarios contain no real data. That is one reason to use the fallback for the most sensitive subjects, such as the exception log or audit findings, even when you could use your own organization.

Every practice card carries a fallback scenario. The tiles give their scale, read from the lessons.

There are 97 practice cards in Modules 1 to 11, and 97 of them carry a fallback: every one. The organizations range from 70 to 2,000 people. And there is no continuity between them: each stands alone.

A fallback is a short paragraph describing an organization: its size, its sector, what it does, and the facts the practice needs. A practice on supplier tiering gets an organization with suppliers of different kinds.

A practice on a framework mapping gets an organization with the frameworks in question. Most open with "Use a" and the organization's size; a few hand you a short document from one, such as a policy or a clause, to work on.

The organizations span sectors: software companies, dental practice groups, universities, logistics firms, health-tech vendors, architecture practices, insurance processors and more. Each is chosen because its sector makes the practice's judgment real. A dental practice group has patient records and card payments; a university faculty has research data on departmental servers.

A fallback is deliberately short. It gives you what a real program would know at the start of the task, not everything. The rest you assume, and section 7 sets out how.

A fallback that answered every question would teach you to fill in forms, not to make judgments. Expect to read it twice: once for the facts given, and once for the facts the practice needs that it leaves out.

The fallbacks are not answer keys. The lesson itself shows the method on its own worked example. The fallback gives you a different organization, so that you apply the method rather than copy the example. Two readers given the same fallback can reach different, equally sound artifacts, provided each states its basis.

The course has no running case company. Each lesson uses its own worked example, and each practice card its own fallback, and no lesson continues a case from an earlier one.

That is a choice with a reason, and the comparison shows it.

With one running case, what you remember is the case's facts; every new subject is read through the same company; a missed lesson leaves later ones depending on it; and at work, your organization is not that company. With a new case each lesson, what you remember is the method; each subject is met on an organization chosen for it; nothing later depends on a lesson you missed; and reading a new organization is itself practiced.

A method learned on one organization tends to stay attached to it: you remember that the finance team owned the payroll risk, not why a risk owner should be the person accountable for the outcome. Meeting the method on a different organization each time separates the method from the case.

It also matches the work. A GRC practitioner rarely works on one organization for long without meeting others: a consultant moves between clients, an auditor between auditees, and an in-house practitioner reads suppliers' reports and customers' questionnaires. Reading a short description of an unfamiliar organization and seeing what matters in it is a skill in itself, and the fallbacks practice it 97 times.

The cost is that the fallback route does not accumulate. A risk register from the Module 5 fallback is not used by the Module 9 fallback. If you want a cumulative set of records, the own-organization route gives it, or you can pick one fallback organization you like and carry it forward yourself, adding your own assumptions as you go.

If you carry one forward, keep a page of the facts you have assumed about it. By Module 11 that page is a description of a whole organization, and every artifact you built on it should agree with it.

Each lesson's worked example follows the same rule. It is chosen for the lesson's subject, described in the lesson's introduction, and does not appear elsewhere. When a lesson names an organization, you never need to have read another lesson to follow it.

Every fallback leaves gaps, and how you fill them is part of the practice. The transform shows the difference between filling a gap silently and stating the assumption.

Filled silently, a gap leaves a rating or a decision with no visible basis. "Rated the phishing risk as likely" invites the question: likely on what basis? "Treated the payroll provider as critical": the scenario did not say so. "Picked a 30-day review cycle": why 30?

Stated, each assumption makes the basis visible. "Assumed: phishing reported monthly in the ticket log, so likely" can be challenged on its fact. "Assumed: payroll provider holds bank details for all staff, so critical" makes the tiering follow from a stated fact. "Assumed: policy calls for monthly review, so 30 days" gives the number a source, even an assumed one.

The transform's note gives the reason this matters beyond the course: a stated assumption is how a real program handles missing information too. Risk assessments are made on incomplete information as a rule. A program that records what it took as true and why can revisit the decision when the fact changes; one that did not cannot tell which decisions the new fact affects.

Keep assumptions reasonable for the organization described. A 250-person firm with a managed IT provider is unlikely to have a 24-hour security operations center; assuming one makes the practice easier and less useful. When in doubt, assume the harder case. A useful check is to ask whether someone who works at an organization like the one described would accept the assumption without argument.

The same habit applies on the own-organization route, where you will often not know a fact and not be able to find it in the time you have. Write the assumption, and note who could confirm it. When they confirm or correct it, update the artifact and remove the label.

What you build needs a home. The record sets out where practice artifacts are kept.

Artifacts for your organization go into its own program file, in approved storage, as lesson 2.8 sets out. Fallback work goes into a separate study file, one folder per module. Each artifact is named by lesson number, with the date you built it.

Assumptions are recorded in the artifact or beside it. The versions register, started in lesson 0.3's practice, sits at the top. And real and fallback artifacts are never mixed in one file.

The note under the record gives the reason for that last rule: a fallback artifact in a real program file can be mistaken for a decision your organization took. A risk register entry for a fictional dental practice, filed among your company's real risks, is confusing at best. At worst, it is read by an auditor as a real record.

Lesson 2.8 teaches the program file in full: the document hierarchy, how registers link, the evidence library, and naming, versioning and retention. If you are building on your own organization, read it before you file much, and set the file up as it describes. If you are building on fallbacks, a folder per module with a file per artifact is enough.

Any format will do. The course's artifacts are documents, registers and short records; a word processor and a spreadsheet hold all of them. Lesson 2.8 compares spreadsheets with GRC platforms; for practice, use what you have. What matters is that each artifact can be found, read and dated by someone other than you.

Keep the file once the course is done. The artifacts are a record of what you can do, and the own-organization ones are a program's first records. Several will need review on the cycle the lesson that built them set. A program that started as practice artifacts is still a program, provided each artifact is reviewed and approved as its lesson describes before it is relied on.

There is no marking service for the practice cards. You check your own work against the lesson. The evaluator shows a check on one artifact.

A risk register entry built in lesson 5.1's practice is checked against the lesson that taught it, with one rule: each field the lesson requires is present and has a basis. Every required field is filled, compared with the record the lesson shows. The owner is a named role, not "IT" or "the business".

The rating has no stated basis: likelihood is given with no reason, so the reason or the assumption must be added. Versions are stated where frameworks are cited: the control reference names SP 800-53 Rev. 5. And the entry contains nothing it should not: no names, secrets or exploitable detail.

The evaluator's note gives the principle: the lesson is the answer key. Each lesson sets out, on its worked example, the shape of the record its practice asks for. Your artifact will differ in its facts and should match in its shape: the same fields, filled with the same discipline.

The exercise lessons go further. Each one runs a module's whole method through on one organization and shows its outputs, so you can compare your full set of artifacts, not just one.

Two checks apply to every artifact, whatever the lesson. Does each judgment have a stated basis? And would the artifact survive being read by someone who was not there when you wrote it? A risk owner who has to ask what an entry means, or an auditor who has to ask why a rating was chosen, has found a gap the method was meant to close.

If you can, have someone else read one artifact per module. A colleague in GRC, security or audit will find what self-checking misses: the person who did the work is the worst placed to see its gaps.

Most readers take this course alongside a job. The gate shows how to pace the practice.

If you are working through the course alongside a job, do one card per sitting: read the lesson, then build its artifact while it is fresh.

If you read several lessons without practicing, catch up at the exercise: do the module's exercise lesson in full, because it uses the whole method. If a practice needs facts you cannot get this week, note it, use the fallback now, and redo it with real facts later.

The gate's foot gives the reason for keeping up: the practice is where the method becomes yours. Reading without it gives you the vocabulary and not the skill.

A practice card is sized for a sitting. Most ask for one entry, one clause or one short record, not a whole document. The exercise lessons are larger, and are worth a longer block of time. If one takes much longer, it is usually because a fact is missing; assume it, note it, and finish.

There is no deadline, and the course does not track your practice. The exam tests the method, not your artifacts, but the method is far easier to apply under exam conditions when you have applied it 97 times already. The order matters more than the speed: each module's practices build on the records of the modules before it, so take them in sequence even when you take them slowly.

If you fall behind, do not try to catch up on every card. Do the next lesson's practice, and the module's exercise. The exercise uses everything the module taught, so it repairs most gaps on its own. Then return to the cards you skipped when a real need for that artifact arises at work; the lesson will still be there, and the need will make the practice better.

Every lesson in Modules 1 to 11 ends with a practice card asking for one artifact, built from your own organization with permission or from the fallback scenario in the card.

Use your organization where you can, part of it where you must, and the fallback where you cannot; keep secrets, unneeded personal data and exploitable detail out of anything you build. Fill a fallback's gaps with stated assumptions, keep real and fallback work in separate files, check each artifact against the lesson that taught it, and practice one card per sitting.

Versions this lesson relies on: NIST SP 800-53 Rev. 5, release 5.2.0 (27 August 2025); AICPA 2017 Trust Services Criteria, revised points of focus (2022).