3 Free GRC Portfolio Projects for Beginners

If you're trying to get into Governance, Risk and Compliance, project advice can get abstract quickly.

Search for GRC projects and you'll often find suggestions to read a framework, write a policy, build a risk register or complete a sample questionnaire. Those can all be useful exercises. The problem is that GRC work is not just knowing what a framework says.

You have to take incomplete information, decide what matters, connect technical conditions to business impact, evaluate the evidence in front of you and explain what the organization should do next.

That's the progression behind these three projects.

Each project gives you a fictional business case with enough context and evidence to make a real decision. You will build a cybersecurity risk register, evaluate a proposed AI use case and conduct a third-party vendor risk assessment.

The goal isn't to prove that you read NIST guidance. It's to prove that you can use it.

Who Are These GRC Projects For?

These projects are aimed at someone preparing for an entry-level GRC Analyst, Cybersecurity Risk Analyst, Security Compliance Analyst, Third-Party Risk Analyst or similar governance and risk role.

You do not need previous GRC experience. Some basic cybersecurity knowledge will help, particularly around concepts such as access control, vulnerabilities, backups, MFA, SaaS, logging, customer data and security controls.

You also do not need to know every framework before starting.

The projects introduce the relevant guidance where it matters, then ask you to apply it to the case. That is much closer to the skill you're trying to demonstrate than memorizing control numbers without business context.

Three projects that you understand and can defend are more useful than a folder full of templates you cannot explain.

Why These Three Projects?

We used a few requirements when selecting them.

There is another rule behind the series:

Reading the framework isn't the project. Applying it to a decision is the project.

Reading NIST SP 800-30 is useful. Building and defending a risk register from imperfect evidence is the project.

Reading the NIST AI RMF is useful. Deciding whether an AI use case should proceed, under what conditions and with what monitoring is the project.

That difference matters when you're trying to show an employer what you can actually do.

The Three Projects

The projects build on one another, but each can still stand on its own.

One Company, Three GRC Assignments

All three projects take place inside Avenloft Systems Group, a fictional B2B software company created for this series.

That continuity is intentional.

The company, employees, systems, business objectives and governance structure stay consistent from one case to the next. Information introduced in the first project can matter again later, just as it would if you were actually working inside the same organization.

Each project includes a downloadable Avenloft case packet designed to resemble an internal assignment rather than a classroom worksheet. The packets provide the business context, evidence, stakeholder information and methodology you need.

Your job is to do the analysis.

The company, employees, vendors, internal records and events used in the training cases are fictional. Where domains are needed, the case materials use reserved example namespaces.

Project 1: Build a Cybersecurity Risk Register

Governance, Risk and Compliance work often starts with a simple question:

What could prevent the business from achieving an objective, how serious would it be, and what should the organization do about it?

A cybersecurity risk register is one place those decisions are documented. A useful entry does more than list a technical problem. It connects a credible event or condition to a business impact, considers the controls already in place, records the risk that remains and gives leadership something they can act on.

For this project, you will work as a junior GRC analyst for Avenloft Systems Group, the fictional company used throughout this GRC project series.

What You're Learning

A technical finding and a risk are not the same thing.

Critical vulnerability on Partner Portal

is a finding.

A risk statement explains what could happen because of that condition and why the business should care.

A useful pattern is:

If [event or threat] occurs alongside [condition or weakness], then [asset, process or objective] may experience [business impact].

You will also work with two different views of risk:

• Inherent risk: the risk before giving credit to existing safeguards.
• Residual risk: the risk remaining after considering the controls currently in place.

For both, use the qualitative likelihood-and-impact matrix from NIST SP 800-30 Rev. 1, Appendix I, Table I-2, included in the case packet. The matrix uses the values Very Low, Low, Moderate, High and Very High rather than a made-up numerical score.

The broader risk-register approach is also informed by NIST IR 8286 Rev. 1 and NIST IR 8286A Rev. 1.

A Quick Example

Suppose a company performs nightly backups but has not tested a full restoration in more than a year.

The risk is not simply:

Backups have not been tested.

A stronger risk statement might describe the possibility that a system outage or destructive event occurs and the organization discovers that its recovery process cannot restore critical services within the time the business expects.

The backups are an existing control. They matter.

The lack of recent recovery testing also matters.

Your job as the analyst is to decide what those facts mean together.

Download and Verify the Case File

Case file: GRC-RISK-001 (Build a Cybersecurity Risk Register).

The packet contains the information you would receive for the assignment: Avenloft's business context, technology environment, risk appetite, existing controls, security observations, stakeholder notes, the NIST risk matrix and the required deliverables.

Download the case file: avenloft-risk-register-case.pdf

Before opening it, it is best practice to verify that the file you downloaded matches the one published here. Open PowerShell in the folder containing the PDF and run:

Get-FileHash .\avenloft-risk-register-case.pdf -Algorithm SHA256

Published SHA-256:

1b9ea44c5b3e36f679afca9c4912fc0cd7eba084e952590b7a333b4cfb17549d

You can also upload the PDF to VirusTotal to see its SHA-256 and check it against multiple security engines. Expect it to come back clean. These are static PDFs: no active content, no macros and no embedded files. Any links they contain point only to public reference material such as NIST publications, plus the standard open-source font metadata (SIL Open Font License) embedded by the document's typeface. The company, people and events in the case are fictional.

Your Project

Review the case packet and build a cybersecurity risk register containing approximately 8 to 12 risk scenarios.

Do not create one risk simply because one observation exists in the packet. Several observations may support the same underlying risk, and a single observation may affect more than one business objective.

For each risk you decide belongs in the register, document enough information for another person to understand:

• the risk scenario
• the business objective, process or asset affected
• the evidence that supports the risk
• inherent likelihood and impact
• inherent risk level
• existing controls
• residual likelihood and impact
• residual risk level
• treatment recommendation
• accountable risk owner
• assumptions or information that still needs validation

If the packet does not give you enough information to make a confident determination, say so rather than inventing a fact.

Questions Your Analysis Should Be Able to Answer

When you finish the register, you should be able to answer:

1. What could realistically go wrong?
2. Which Avenloft business objectives or critical processes would be affected?
3. What evidence in the case packet supports each risk?
4. How serious is the risk before considering existing controls?
5. Which controls already reduce the likelihood or impact?
6. What risk remains after those controls are considered?
7. Which risks exceed or conflict with Avenloft's stated risk tolerance?
8. What should happen next: mitigate, avoid, transfer/share or accept?
9. Who should own the risk?
10. Which five residual risks deserve leadership's attention first, and why?
11. Which conclusions depend on information that still needs to be validated?

There may be more than one defensible answer. What matters is whether your assessment is consistent with the evidence and whether you can explain your reasoning.

What to Document

For your portfolio, keep the evidence focused on your analysis rather than every working page.

Useful material includes:

• a view of the completed risk register
• two or three strong risk entries
• your top-five residual-risk prioritization
• the NIST risk-rating methodology you used
• one example showing how existing controls changed your assessment
• one example where you documented an assumption or a "Needs validation" item
• your executive risk summary

Portfolio Artifacts

By the end of the project, you should have two primary artifacts.

1. Cybersecurity Risk Register: a completed register containing approximately 8 to 12 risk scenarios with inherent risk, existing controls, residual risk, treatment and ownership.
2. Executive Risk Summary: a one-page management-facing summary of the most important residual risks, recommended actions and material uncertainties.

Those are the pieces worth keeping for your portfolio.

Skills you can document: Governance, Risk and Compliance (GRC), cybersecurity risk assessment, risk registers, inherent risk, residual risk, likelihood and impact analysis, risk treatment, control assessment, risk ownership, NIST SP 800-30, NIST IR 8286, executive communication and security documentation.

Project 2: Evaluate a New AI Use Case

AI governance is not just writing an AI policy.

Sooner or later, someone in the business wants to use an AI system for a real task. GRC has to understand what the system is supposed to do, what information it touches, who remains accountable for the outcome and whether the organization is willing to accept the risk that remains.

For this project, you will return to Avenloft Systems Group as a junior GRC analyst. Customer Success wants approval to pilot an AI-enabled SaaS tool that summarizes support calls and tickets.

Your job is to decide whether the pilot should proceed.

What You're Learning

The NIST AI Risk Management Framework (AI RMF) organizes AI risk management into four functions:

• Govern: establish accountability, policy, inventory and risk-management expectations.
• Map: understand the intended use, context, users, data, dependencies and potential impacts.
• Measure: evaluate the risks and limitations using tests, evidence and other available information.
• Manage: prioritize the risks, decide what should happen and monitor the system over time.

The framework is not a checklist. You will use those functions as a way to organize the review.

Because the proposed tool uses generative AI, the case also draws from the NIST Generative AI Profile (NIST AI 600-1). Several of its risk areas are particularly relevant to a support-summarization system, including confabulation, data privacy, human-AI configuration, information integrity, information security and third-party component integration.

A Quick Example

Suppose an AI tool summarizes a support call and states that the customer already restarted a system.

The original transcript never says that.

That is more than an "AI hallucination" to put on a checklist. If the incorrect statement becomes part of the support record, another agent may rely on it later and skip a troubleshooting step that never occurred.

Now the governance questions become more useful:

How often does this happen? Can the agent see the source? Is human review required? Where is the generated summary stored? How would Avenloft detect if quality gets worse after a model update?

That is the level of analysis this project is asking for.

Download and Verify the Case File

Case file: GRC-AI-002 (Evaluate a New AI Use Case).

The packet contains the proposed use case, data flow, fictional vendor responses, retention and subprocessor information, support-data profile, pre-pilot test results, stakeholder notes, NIST guidance and the required deliverables.

Everything about Avenloft and the fictional AI vendor is provided inside the case.

Download the case file: avenloft-ai-use-case-review.pdf

Verify it the same way. In the folder containing the PDF, open PowerShell and run:

Get-FileHash .\avenloft-ai-use-case-review.pdf -Algorithm SHA256

Published SHA-256:

57b6c081406fe549efc7d4fa4968151a720d6a2f0525d65f6b0bb8c24cdb0c92

Your Project

Review the case and determine whether Avenloft should Approve, Conditionally Approve, Defer or Reject the proposed Customer Success pilot.

Start by documenting the use case itself. Be specific about:

• why the business wants the AI system
• who will use it
• what the AI actually does
• what information enters the system
• what the system produces
• which vendors or subprocessors are involved
• where human review occurs
• what is explicitly outside the approved scope

Then identify the material risks supported by the evidence in the packet.

Use Avenloft's existing qualitative risk method to rate the risks. The packet includes the same NIST SP 800-30 likelihood-and-impact matrix used in Project 1 so that Avenloft's risk language remains consistent.

Do not assume that a proposed control already exists. If your recommendation depends on SSO, shorter retention, contract language, testing or another safeguard that has not yet been implemented, record it as a condition of approval rather than a current control.

Questions Your Analysis Should Be Able to Answer

1. What business problem is the AI system intended to solve?
2. What data will Avenloft send to the service, and is all of it necessary?
3. What happens to that data after it leaves Avenloft?
4. Which third parties or AI components are part of the service?
5. What do the supplied test results tell you about reliability and unsupported output?
6. Is the proposed human review meaningful enough for the way the output will be used?
7. Which vendor statements still need validation or stronger contractual language?
8. What controls should be required before the pilot begins?
9. What should Avenloft monitor during the pilot?
10. What changes or events should trigger a new review or shutdown?
11. Should the pilot proceed, and why?

There is not necessarily one correct final decision. A strong submission makes the reasoning visible and defines the boundaries clearly enough that someone else could understand what was approved months later.

What to Document

Useful portfolio evidence could include:

• your completed AI use-case inventory record
• two or three of the strongest AI risk entries
• a simple view of the approved data flow and pilot boundaries
• the NIST AI RMF functions or GAI risk areas that materially informed your review
• the controls or conditions you required
• the monitoring and reassessment triggers you selected
• your final decision memo

You do not need to publish the entire case packet or every working note. The useful artifacts are the pieces that show how you evaluated the use case and reached a governance decision.

Portfolio Artifacts

By the end of the project, you should have three primary artifacts.

1. AI Use-Case Inventory Record: a structured record documenting the business owner, purpose, users, AI capability, data, dependencies, human oversight, deployment status and review owner.
2. AI Risk Assessment: a documented assessment of the material risks, evidence, current controls, required conditions, residual risk and monitoring responsibilities.
3. AI Governance Decision Memo: a short management-facing decision that approves, conditionally approves, defers or rejects the pilot and defines the approved scope, required controls, prohibited uses and reassessment triggers.

Those are the pieces worth keeping for your portfolio.

Skills you can document: Governance, Risk and Compliance (GRC), AI governance, NIST AI RMF, NIST AI 600-1, AI risk assessment, AI use-case inventory, third-party AI risk, data governance, human oversight, generative AI risk, risk treatment, executive communication and security documentation.

Project 3: Conduct a Third-Party Vendor Risk Assessment

A vendor security review is not a questionnaire-completion exercise.

A third party may have encryption, a SOC 2 report and a penetration test and still create meaningful risk for your organization. The useful question is not simply "Does the vendor have security controls?" It is:

What does this relationship expose, what evidence supports the vendor's claims, what risk remains, and what should the business require before continuing?

For this project, you will return to Avenloft Systems Group as a junior GRC analyst. A Customer Success analytics vendor was originally onboarded without a formal security review because its annual spend fell below the old procurement threshold. The contract is now approaching renewal.

Your job is to review the relationship and make a defensible recommendation.

What You're Learning

Third-party risk starts with understanding the relationship itself.

The NIST Cybersecurity Framework (CSF) 2.0 includes a Cybersecurity Supply Chain Risk Management category, GV.SC, that addresses supplier criticality, contractual requirements, due diligence, ongoing assessment, incident involvement, monitoring and activities after a relationship ends.

NIST also publishes practical supply-chain guidance. NIST SP 1305 focuses on using CSF 2.0 for cybersecurity supply-chain risk management, while NIST SP 1326 describes due diligence as an investigative process for gathering relevant supplier information so acquisition and relationship decisions can be made with better context.

You are not going to turn those publications into a checklist. They provide the governance idea behind the project: know the vendor, understand the exposure, evaluate the evidence, respond to the risk and keep monitoring the relationship.

A Quick Example

Suppose a vendor tells you that customer data is encrypted at rest.

That is useful information, but it does not answer every question about the relationship.

If your users authenticate with passwords, MFA is optional, and the vendor recently experienced credential-stuffing against customer accounts, the more important risk may involve how an attacker could gain access to your organization's data through a compromised customer account.

Encryption at rest is still a control. It just does not solve that particular scenario.

That is the kind of distinction this project asks you to make.

Download and Verify the Case File

Case file: GRC-TPRM-003 (Conduct a Third-Party Vendor Risk Assessment).

The packet contains the vendor relationship, data flow, fictional security questionnaire, security architecture information, synthetic SOC 2 Type II summary, synthetic penetration-test summary, incident history, contract excerpts, recovery information, stakeholder notes and the assessment fields you need to complete the review.

Everything about the vendor is fictional.

Download the case file: avenloft-third-party-risk-review.pdf

Verify it the same way. In the folder containing the PDF, open PowerShell and run:

Get-FileHash .\avenloft-third-party-risk-review.pdf -Algorithm SHA256

Published SHA-256:

3022bbdd6078ac0f50ddb62faddef29e696af30cea9bfa1774b0892bf8aab20d

Your Project

Review CobaltCedar Analytics, Inc. and its SupportLens service before Avenloft's November renewal.

Start by understanding the relationship rather than the questionnaire.

Document:

• what business process the vendor supports
• what Avenloft data the vendor receives
• how the data reaches the vendor
• what access the vendor has to Avenloft systems
• how operationally important the service is
• which vendor controls are supported by evidence
• which claims are self-attested or incomplete
• which risks remain after current controls are considered

Classify the relationship based on its actual exposure, not annual spend alone.

Then use Avenloft's existing qualitative risk method to assess the material vendor-risk scenarios. The case packet includes the same NIST SP 800-30 likelihood-and-impact matrix used in the earlier Avenloft risk process so the company's risk language remains consistent.

Do not count a proposed control as a current control. If you believe Avenloft should require SSO, mandatory MFA, shorter retention, stronger incident-notification language or another change at renewal, record it as a finding or condition, then assess whether the current residual risk is acceptable while that work is still open.

Questions Your Analysis Should Be Able to Answer

1. What does Avenloft rely on CobaltCedar to do?
2. What customer information does the vendor receive, and how sensitive is it?
3. Does the vendor have direct access to Avenloft systems or only the data Avenloft sends?
4. How critical is the service to Avenloft's operations?
5. Which questionnaire responses are supported by independent or documentary evidence?
6. What does the synthetic SOC 2 report support, and what does it not prove?
7. What does the penetration-test evidence tell you about the current security posture?
8. How should the March credential-stuffing incident affect your analysis of Avenloft's current account configuration?
9. Which contract, retention, deletion, incident-notification or subprocessor issues matter to the relationship?
10. What are the most important residual risks?
11. Which findings should be conditions of renewal, and which can be monitored afterward?
12. What evidence or answers still need validation?
13. Should Avenloft renew, renew with conditions, pause for remediation or exit the relationship?
14. What should trigger reassessment after the decision?

There may be more than one defensible decision. What matters is whether the recommendation is tied to the evidence, Avenloft's exposure and the risk that remains.

What to Document

Useful portfolio evidence could include:

• your completed vendor relationship and criticality profile
• a concise evidence-review table showing what was supplied and what it supports
• two or three strong vendor-risk scenarios
• your most important findings and remediation requirements
• one example where vendor evidence reduced your concern
• one example where a vendor statement required additional validation
• your final vendor decision memo

You do not need to publish the entire questionnaire or case packet. The useful artifacts are the pieces that show how you evaluated a third party and turned evidence into a risk decision.

Portfolio Artifacts

By the end of the project, you should have three primary artifacts.

1. Vendor Risk Assessment: a structured assessment documenting the relationship, criticality, evidence, material risk scenarios, current controls and residual risk.
2. Findings and Remediation Tracker: a short working tracker showing the gaps that matter, required actions, accountable owners, target dates and status.
3. Vendor Decision Memo: a management-facing recommendation to renew, renew with conditions, pause for remediation or exit, including the rationale, required conditions, monitoring and reassessment triggers.

Those are the pieces worth keeping for your portfolio.

Skills you can document: Governance, Risk and Compliance (GRC), third-party risk management (TPRM), vendor risk assessment, cybersecurity supply chain risk management, NIST CSF 2.0, NIST SP 1305, NIST SP 1326, NIST SP 800-161, SOC 2 evidence review, security questionnaires, vendor due diligence, risk treatment, remediation tracking, contract security requirements, executive communication and security documentation.

What Should Go Into Your GRC Portfolio?

You do not need to publish every page you touched while completing the cases.

A strong GRC project shows enough evidence for somebody else to understand the problem, see how you evaluated it and follow the decision you reached.

For these projects, that usually means some combination of:

Do not include an artifact just because it looks formal.

Include it because you can explain what decision it supported.

A simple project write-up is enough:

• Scenario: What was the business asking you to evaluate?
• Objective: What decision or assessment were you responsible for?
• Evidence: What information did you rely on?
• Analysis: How did you interpret the evidence and controls?
• Decision: What did you recommend?
• Next step: What should be treated, monitored, validated or reassessed?

That gives someone reviewing your portfolio enough context to understand the work without turning every project into another case packet.

What These Three Projects Actually Prove

The first project teaches you to move from technical and operational evidence to business risk. You have to decide which observations belong in the register, distinguish inherent from residual risk, account for existing controls and tell leadership what deserves attention first.

The second adds a newer governance problem. Instead of treating AI as automatically good or automatically dangerous, you have to understand the use case, the data, the human oversight, the vendor claims and the test evidence before deciding whether the pilot should proceed.

The third moves the decision outside the company. A vendor may have a SOC 2 report, encryption and a penetration test and still create risk that matters to Avenloft. You have to evaluate the relationship, decide which evidence deserves weight and determine what should be required at renewal.

Together, the projects practice a core part of GRC work:

understand the business, evaluate the evidence, assess the risk, document the decision and communicate what happens next.

You are not pretending to be a CISO, auditor or senior risk executive.

You are showing that you can take a defined GRC assignment, work through the evidence and produce something another person could review and act on.

Those are useful things to be able to show.

Turn the Work Into a GRC Portfolio

Completing the projects gives you practice. Documenting them gives you proof.

The risk registers, review tables, evidence and analyst notes you created here are exactly the kinds of artifacts you can turn into project write-ups on LabList.

Instead of leaving the work scattered across spreadsheets and documents on your computer, build a profile where an employer can see the project, understand the business problem, review the evidence you chose to share and connect that work to the GRC skills you're claiming.

You can start with 14 days of full access with no credit card required. Build your portfolio, publish it and share it while you decide whether LabList works for you.

You are never charged unless you add a payment method yourself. After the 14 days, you decide whether you want to become a member and keep adding, editing and growing your portfolio.

Build your GRC portfolio on LabList