GRC Intermediate Guide

1. Intermediate GRC Mindset

At foundation level, you learn the terms. You learn what a risk is, what a control is, why evidence matters, and why business owners need to be involved.

At intermediate level, you start using those ideas in motion. A risk is no longer just a definition in notes. It becomes a tracked item with an owner, a rating, a treatment plan, evidence, and a decision someone must stand behind.

A professional GRC person does not only ask:

"Are we compliant?"

They ask:

"What are our most important risks, how well are our controls working, where is the evidence, who owns the decision, and what should leadership do next?"

Intermediate GRC requires balance.

You must understand:

• Technical security
• Business priorities
• Legal and regulatory expectations
• Audit evidence
• Risk language
• Human behavior
• Practical constraints

In real companies, security is rarely perfect.

Your job is to help the company make informed decisions without pretending every issue has the same urgency. Some risks need fast remediation. Some need compensating controls. Some need formal acceptance. Your value is helping people choose the right path and prove what happened.

2. How to Think Like a GRC Professional

A technical person may start with the flaw. A GRC professional starts with the decision that needs to be made.

Before you write a finding, ask: what asset is affected, who owns it, what could happen, how likely is it, what controls already exist, and what decision do we need from the owner?

Weak Thinking

"This system is vulnerable. Fix it."

Better Thinking

"This vulnerability affects an internet-facing system that stores customer data. The likelihood is high because exploitation is possible remotely. The impact is high due to potential data exposure. This should be treated as a high risk and remediated within the patch SLA."

Senior Direction

"This risk should be prioritized because it affects a critical business service, could breach customer contract requirements, and may create regulatory and reputational impact. If remediation is delayed, leadership should formally accept the residual risk with a compensating control."

Notice the difference. The senior version does not sound dramatic. It gives context, impact, ownership, and a practical path forward.

3. Writing Professional Risk Statements

A risk statement is not just a longer way to say "something is bad." It should explain why the weakness matters in business terms.

Good risk statements are specific enough to act on but not so technical that only one engineer understands them.

A good risk statement usually includes:

• Cause
• Event
• Impact

Formula:

Due to [weakness], there is a risk that [event] may occur, resulting in [business impact].

If the statement feels vague, test it with three questions: what weakness causes the risk, what event could happen, and why would the business care?

Example 1: Missing MFA

Due to lack of MFA on privileged accounts, there is a risk that attackers may gain unauthorized administrative access, resulting in data exposure, system disruption, or unauthorized changes.

Example 2: No Vendor Review

Due to absence of vendor security assessments, there is a risk that third-party providers may expose company data or services, resulting in data breach, service disruption, or contractual non-compliance.

Example 3: Weak Logging

Due to insufficient logging and monitoring, there is a risk that security incidents may not be detected or investigated in a timely manner, resulting in prolonged attacker access and increased business impact.

4. Building a Risk Register

A practical risk register should be simple enough to maintain but detailed enough to support decisions.

Think of it as the team's shared memory for risk. Without a register, issues live in chat messages, old tickets, audit comments, and people's heads. With a register, the organization can see what is open, who owns it, what matters most, and what proof exists.

Do not make the register complicated on day one. Start with the fields needed to make a decision, then add more detail only when the process needs it.

Recommended Columns

Example

Here is how the missing MFA issue could look once it is written as a trackable risk instead of a casual complaint.

5. Risk Rating in Practice

Many companies use a simple 3x3 or 5x5 matrix.

The matrix is not magic. It is a conversation tool. It helps people compare risks consistently, but the rating still depends on good judgment and clear evidence.

For beginners, a 3x3 matrix is easier to learn because it keeps the decision simple: low, medium, high. Larger matrices can be useful later, but they can also create false precision if the team does not understand the criteria.

3x3 Risk Matrix

Likelihood Factors

Consider:

• Is the system internet-facing?
• Is the vulnerability easy to exploit?
• Are attackers actively exploiting this?
• Are there existing controls?
• Has this happened before?
• Is the user group high-risk?

Impact Factors

Consider:

• Customer data exposure
• Financial loss
• Legal or regulatory impact
• Operational downtime
• Reputation damage
• Contractual penalties
• Safety impact
• Executive concern

A useful habit is to write one short sentence explaining the rating. For example: "Likelihood is high because the service is internet-facing and exploit code is public; impact is high because the service handles customer data."

6. Control Design vs Control Operating Effectiveness

Control testing becomes much easier once you separate two questions: is the control designed well, and is it actually working over time?

A control can fail either way. Sometimes the rule itself is weak. Sometimes the rule is good, but people do not follow it or the system is not configured correctly.

Control Design

Is the control designed properly?

Example:

Company requires MFA only for normal users but not administrators.

Design issue:

The control is poorly designed because privileged accounts are higher risk.

Control Operating Effectiveness

Is the control actually working over time?

Example:

MFA policy exists, but 20 admin accounts do not have MFA enabled.

Operating issue:

The control is not operating effectively.

Professional Language

Instead of saying:

"MFA is broken."

Say:

"The MFA control is not operating effectively because privileged account coverage is incomplete."

That wording is useful because it tells the owner what failed and where to look. It also keeps the conversation professional instead of blaming a person or team.

7. Control Testing

Control testing verifies whether a control works in the real process, not just in policy language.

The basic flow is simple: understand the control, collect evidence, compare evidence against the requirement, document the result, and follow up on gaps.

Example Control

User access must be reviewed quarterly.

Test Steps

For this control, you are not trying to prove that the company has a nice access review policy. You are checking whether the review actually happened and whether the company acted on the results.

1. Obtain list of active users.
2. Obtain previous quarter access review evidence.
3. Check if review was completed.
4. Check if reviewer was appropriate.
5. Check if exceptions were tracked.
6. Check if access removals were completed.
7. Document result.

Possible Result

Control partially effective. Quarterly access review was completed, but evidence did not show whether identified removals were performed.

"Partially effective" is common in real work. It means the control is not completely broken, but the evidence shows a gap that should be fixed.

8. Access Review

Access review is one of the most common GRC activities.

The goal is not to make managers click approve on a spreadsheet. The goal is to catch access that no longer makes sense before it becomes a security or audit problem.

Purpose:

Ensure users have only the access they need.

What to Review

Start with accounts that can cause the most damage, then expand to normal users and lower-risk systems.

• Active users
• Privileged users
• Shared accounts
• Dormant accounts
• Former employees
• Third-party accounts
• Admin group membership
• Critical application roles

Evidence Needed

Good evidence should show the list reviewed, who reviewed it, what they decided, and what changed after the review.

• User access export
• Reviewer approval
• List of removed users
• Tickets showing changes
• Date of review
• Sign-off

Red Flags

• Former employees still active
• Admin access without approval
• Shared admin accounts
• No business owner review
• No evidence of removals
• Review done by IT only without business owner validation

A business owner matters because IT may know how access is configured, but the business owner knows whether that access is still needed for the job.

9. Joiner, Mover, Leaver Process

This is also called JML. It covers the access lifecycle: what happens when someone joins the company, changes role, or leaves.

JML is where many access problems begin. People often get access when they join, collect more access as they move, and keep old access because nobody removes it.

Joiner

A new employee joins and needs access to do their job.

Controls:

• Access request approved
• Role-based access assigned
• MFA enabled
• Security training completed

Mover

An employee changes role, team, project, or privilege level.

Controls:

• Old access removed
• New access approved
• Privileged access reviewed

Leaver

An employee, contractor, intern, or vendor user leaves.

Controls:

• Account disabled quickly
• VPN/email/app access removed
• Assets returned
• Shared passwords changed if needed
• Sessions revoked

Risk Example

Due to weak leaver process, former employees may retain access to company systems, resulting in unauthorized access or data theft.

For testing, pick a small sample of joiners, movers, and leavers. Check whether access requests, approvals, removals, and timestamps match the process the company says it follows.

10. Vendor Risk Management

Vendor risk means checking the risk introduced by outside companies that handle your data, support your systems, or become part of your service delivery.

The simple question is: if this vendor makes a security mistake, can it hurt our customers, operations, legal position, or reputation?

Vendors may access:

• Customer data
• Internal systems
• Cloud platforms
• Source code
• Financial information
• Employee data

Vendor Risk Questions

Ask questions that match the vendor's real access. A lunch supplier and a cloud hosting provider should not go through the same depth of review.

• What data will the vendor access?
• Is the vendor critical to operations?
• Where is data stored?
• Does the vendor have security certifications?
• Does the vendor use encryption?
• Does the vendor have incident response procedures?
• Does the contract include security requirements?
• Can the vendor subcontract work?
• What happens if the vendor is breached?

Vendor Risk Tiers

Tiering helps you spend time where the risk is higher. The goal is not to create paperwork for every vendor. The goal is to avoid missing the vendors that could seriously affect the business.

Evidence to Request

Request evidence that matches the risk tier. For a high-risk vendor, you may need formal reports and contract requirements. For a low-risk vendor, a short questionnaire may be enough.

• Security questionnaire
• ISO 27001 certificate
• SOC 2 report
• Penetration test summary
• Data processing agreement
• Incident response policy
• Business continuity plan
• Access control policy

11. Audit Readiness

Audit readiness means being prepared before auditors ask. It is much calmer to maintain evidence throughout the year than to search for screenshots the night before an audit call.

A good GRC habit is to treat evidence like a living record, not a one-time collection exercise.

Common Audit Evidence

• Approved policies
• Risk register
• Asset inventory
• Access reviews
• Vulnerability reports
• Patch reports
• Incident records
• Backup test reports
• Security training records
• Vendor assessments
• Change management tickets

Good Audit Behavior

• Be honest.
• Provide only requested evidence.
• Do not guess.
• Do not hide known issues.
• Track evidence clearly.
• Keep timestamps and owners.
• Explain compensating controls if something is missing.

If you do not know the answer, say that you will verify and follow up. Guessing creates more risk than a short delay.

Bad Audit Behavior

• Sending random screenshots
• Changing evidence after request
• Giving verbal answers only
• Over-sharing unrelated issues
• Blaming teams
• Claiming controls work without proof

12. Evidence Management

Evidence is how GRC moves from "we believe this control works" to "we can show this control worked."

Evidence should answer:

What control was performed, when, by whom, and what was the result?

Good Evidence Example

For patch management:

• Vulnerability scan report dated March 31
• Patch deployment report dated April 5
• Exception list for systems not patched
• Approval for exception
• Retest report showing vulnerabilities fixed

Poor Evidence Example

• Screenshot of dashboard with no date
• Verbal statement: "We patch monthly"
• Old report from last year
• No system list
• No exception tracking

The difference is traceability. Good evidence lets another person understand the control without needing a long verbal explanation from you.

13. Policy Management

Policies should not be written and forgotten.

A policy is useful only if people can understand it, owners can enforce it, and controls can be tested against it. A copied template with no real owner is not governance.

Policy Lifecycle

1. Draft
2. Review
3. Approve
4. Publish
5. Communicate
6. Train
7. Review periodically
8. Update when needed

Important Policies

Small and medium companies should usually have:

• Information Security Policy
• Access Control Policy
• Password/MFA Policy
• Acceptable Use Policy
• Incident Response Policy
• Data Classification Policy
• Backup Policy
• Vendor Security Policy
• Change Management Policy
• Asset Management Policy

Policy Quality Checklist

A good policy should define:

• Purpose
• Scope
• Roles and responsibilities
• Requirements
• Exceptions
• Enforcement
• Review cycle
• Approval owner

Keep the language direct. For example, "All privileged accounts must use MFA" is stronger than "MFA should be considered where appropriate."

14. Exception Management

Real companies always have exceptions. The professional move is not to pretend exceptions do not exist. The professional move is to document them, reduce the risk, and make sure the right owner accepts the remaining risk.

Example:

A legacy system does not support MFA.

Bad approach:

Ignore it.

Professional approach:

• Document the exception.
• Explain the risk.
• Define compensating controls.
• Get owner approval.
• Set expiry date.
• Review regularly.

An exception should never be permanent by default. If it has no expiry date, it slowly becomes an unofficial standard.

Exception Template

15. GRC and Vulnerability Management

Vulnerability management is where technical severity and business risk often get mixed up.

A technical scanner may say:

Critical vulnerability found.

GRC asks:

• Which asset is affected?
• Is it internet-facing?
• Is it business critical?
• Is exploit available?
• What is the patch SLA?
• Who owns remediation?
• Is there an exception?
• Is risk accepted?
• Was remediation verified?

This does not replace technical vulnerability work. It adds ownership, timelines, exceptions, verification, and reporting so vulnerabilities actually move toward closure.

Patch SLA Example

An SLA gives teams a target for remediation. These numbers are examples; a real company should tune them based on system criticality, exposure, regulatory needs, and available resources.

16. Incident Response from GRC View

SOC focuses on detection and response.

GRC focuses on process, evidence, and improvement.

After an incident, GRC helps answer whether the organization followed its own process and what needs to change so the same weakness does not repeat.

GRC Questions After an Incident

• Was the incident identified quickly?
• Was it classified correctly?
• Was escalation followed?
• Were stakeholders notified?
• Was evidence preserved?
• Was root cause identified?
• Were lessons learned documented?
• Were policies or controls updated?
• Was customer/regulatory notification needed?

Incident Evidence

• Alert records
• Timeline
• Investigation notes
• Affected assets
• Containment actions
• Recovery actions
• Communication records
• Lessons learned report
• Post-incident action items

The evidence should tell the story clearly: what happened, when it was noticed, what was done, who was informed, and what will be improved.

17. Business Continuity and Disaster Recovery

Business continuity and disaster recovery are about keeping the organization alive during disruption. They are related, but they are not the same thing.

Business Continuity

How the business continues during disruption.

Example:

How does the company operate if the office is unavailable?

Disaster Recovery

How IT systems are restored.

Example:

How do we restore the database after ransomware?

Important Terms

These terms matter because they turn vague expectations into measurable targets.

Example

If a payment system has:

• RTO: 4 hours
• RPO: 15 minutes

Then the company expects:

• System restored within 4 hours
• No more than 15 minutes of data lost

For GRC, the key evidence is not only that a plan exists. You also want proof that backups were tested, recovery steps were practiced, and gaps were tracked.

18. Data Classification

Data classification helps decide protection level. Not every file needs the same handling, but sensitive data should not be treated like public marketing content.

The classification label should guide practical controls: who can access the data, where it can be stored, how it is shared, how long it is kept, and how it is deleted.

Simple Classification Model

Controls by Classification

Restricted data may require:

• Encryption
• MFA
• Access approval
• Logging
• DLP
• Retention limits
• Secure deletion
• Strong vendor controls

A common beginner mistake is creating labels but never connecting them to controls. Classification only helps when it changes how data is handled.

19. Privacy Basics

Privacy focuses on personal data: information that can identify a person directly or indirectly.

Security asks whether data is protected. Privacy also asks whether the organization should collect it, why it is used, who it is shared with, and how long it is kept.

Personal data may include:

• Name
• Email
• Phone number
• Address
• Citizenship number
• Financial information
• Health information
• Location data
• Employee records

Privacy Principles

• Collect only needed data.
• Use data for clear purpose.
• Protect data.
• Limit access.
• Do not retain forever.
• Delete securely.
• Notify users when required.
• Review vendors handling personal data.

GRC Privacy Questions

• What personal data do we collect?
• Why do we collect it?
• Where is it stored?
• Who can access it?
• How long do we keep it?
• Which vendors process it?
• What happens if it is breached?

Privacy laws differ by country and sector, so avoid guessing legal requirements. For learning and early practice, focus on data inventory, purpose, access, retention, vendor handling, and breach response.

20. Framework Mapping

Framework mapping means connecting controls from one standard to another.

This is useful because teams usually do not want separate controls for every audit, customer questionnaire, or framework. They want one strong control that can satisfy several requirements when the mapping is accurate.

Example:

Mapping is useful because one control can satisfy multiple requirements.

Example:

Quarterly access review may support ISO 27001, SOC 2, internal policy, and customer requirements.

Be careful with mapping. Similar control topics do not always mean identical requirements. Read the wording before claiming coverage.

21. GRC for Nepali Companies

In Nepal, many companies may not have mature GRC teams yet. That does not mean GRC is impossible. It means the first useful work is often practical cleanup: knowing what exists, who owns it, what risk matters most, and what evidence can be produced.

You may see:

• Informal access processes
• Limited documentation
• Manual evidence collection
• Weak vendor review
• Policies copied from templates
• Security controlled mostly by IT
• Compliance driven by clients or regulators

This is common in growing environments. Your value is helping the company mature step by step instead of shaming teams for not already having a perfect program.

Practical Priorities

For small and medium companies, start with:

1. Asset inventory
2. User access review
3. MFA for critical systems
4. Backup and restore testing
5. Incident response plan
6. Security policies
7. Vendor list and basic risk review
8. Vulnerability management
9. Security awareness training
10. Risk register

Start with controls that reduce real risk quickly. MFA, access review, backups, offboarding, vendor lists, and incident response basics usually give more value than writing a huge policy library nobody reads.

For IT Outsourcing Companies

Focus on:

• Customer data protection
• Developer access control
• Source code security
• Cloud security
• Laptop security
• Employee offboarding
• Client contract requirements
• Secure SDLC
• Evidence for international clients

For Banks and Fintechs

Focus on:

• Strong access controls
• Transaction monitoring
• Audit logging
• Regulatory reporting
• Vendor risk
• Business continuity
• Disaster recovery
• Incident response
• Change management
• Privileged access management

22. Communication Skills

GRC is communication-heavy.

The same issue needs different wording depending on the audience. Engineers need technical detail. Business owners need impact and action. Executives need risk, options, and decisions.

You must talk to:

• IT
• SOC
• Developers
• HR
• Legal
• Finance
• Vendors
• Auditors
• Executives
• Business owners

Technical Message

"Port 3389 is exposed to the internet."

GRC Message

"Remote Desktop exposure increases the risk of unauthorized access and ransomware. This should be restricted through VPN or IP allowlisting."

Executive Message

"This issue increases the likelihood of business disruption. We recommend fixing it within 7 days or formally accepting the risk."

The goal is not to sound less technical. The goal is to make the message useful for the person receiving it.

23. Reporting to Management

A good management report should be simple, but not empty. Management needs enough detail to understand risk, progress, blockers, and decisions required.

Do not report every tiny activity. Report what changed, what is overdue, what risk is increasing, and where leadership help is needed.

Monthly GRC Report Sections

• Top risks
• New risks
• Closed risks
• Overdue remediation
• Audit findings
• Vendor review status
• Security exceptions
• Incident trends
• Policy updates
• Key decisions needed

Example Executive Summary

During this month, three high risks were identified: missing MFA on privileged accounts, incomplete vendor assessments, and delayed critical patching. MFA remediation is in progress and expected to close by month-end. Vendor assessments remain overdue and require business owner support. No critical incidents were reported.

A useful executive summary should be short enough to read quickly and clear enough that the next decision is obvious.

24. Metrics and KRIs

Metrics help show whether security is improving, but bad metrics can create false comfort.

A useful metric should be measurable, tied to risk, and hard to game. "Number of policies written" is less useful than "percentage of critical systems covered by access review."

Useful Metrics

KRI vs KPI

KPI measures performance.

Example:

95% of employees completed training.

KRI measures risk.

Example:

20 privileged users do not have MFA.

In simple terms: a KPI often says how well a process is running, while a KRI warns that risk may be getting too high.

25. How to Apply GRC in Real Work

When you find an issue, slow down enough to turn it into a managed risk. A messy finding becomes useful when it has context, owner, rating, treatment, due date, evidence, and status.

Follow this process:

1. Understand the issue.
2. Identify affected asset or process.
3. Identify business impact.
4. Write a risk statement.
5. Check existing controls.
6. Rate likelihood and impact.
7. Recommend treatment.
8. Assign owner.
9. Define due date.
10. Collect evidence.
11. Track progress.
12. Report status.
13. Verify closure.

Example

Finding:

Developers share one production database account.

Professional handling:

This is the move from technical observation to GRC work. You are not only saying what is wrong. You are creating a path to decision, remediation, and proof.

26. Intermediate Interview Questions

Use these questions for practice, not memorization. A strong answer should show that you understand the process, the evidence, and the business reason behind the work.

Question 1

How do you test whether access review is effective?

Good answer:

I would obtain the user access list, review evidence, approval records, and removal tickets. I would check whether the review was done on time, by the correct owner, whether exceptions were identified, and whether access removals were completed.

Question 2

What is the difference between inherent and residual risk?

Good answer:

Inherent risk is the risk before controls. Residual risk is the remaining risk after controls are applied.

Question 3

How would you handle a vendor with no SOC 2 report or ISO/IEC 27001 certification?

Good answer:

I would not automatically reject them. I would assess the type of data and access involved, send a security questionnaire, review their policies and controls, identify gaps, require compensating controls if needed, and escalate high risks to the business owner.

Question 4

What makes good audit evidence?

Good answer:

Good evidence is relevant, complete, dated, traceable, and shows that the control operated as required.

Question 5

How would you explain a critical vulnerability to management?

Good answer:

I would explain which business system is affected, what could happen if exploited, whether exploitation is likely, what the remediation plan is, who owns it, and when it should be fixed.

27. Common Mistakes at Intermediate Level

Most intermediate mistakes happen when people jump straight from finding a problem to demanding a fix. GRC work needs more structure than that.

Avoid these mistakes:

• Treating compliance as checkbox work only
• Using too much technical language with executives
• Accepting screenshots as evidence without context
• Not assigning risk owners
• Not tracking exceptions
• Confusing vulnerability severity with business risk
• Assuming policy means control is working
• Ignoring vendor risk
• Reporting too many details and no decision points
• Saying "secure" or "not secure" without explaining risk

If you catch yourself doing one of these, return to the basic chain: issue, risk, impact, owner, treatment, evidence, status.

28. Practical Templates

Templates help you write consistently. They should not make your work sound robotic. Fill them with real context, clear ownership, and evidence-based reasoning.

Risk Statement Template

Due to [control weakness], there is a risk that [threat event] may occur, resulting in [business impact].

Control Testing Result Template

The control is [effective / partially effective / ineffective] because [evidence-based reason]. Recommended action is [remediation].

Audit Finding Template

An audit finding should be fair and specific. It should explain the gap without attacking the team that owns the process.

Exception Template

Use this when a control cannot be met right now, but the risk still needs to be visible and approved.

29. Building Toward Professional GRC

To move from intermediate to professional GRC, you need deeper skill in connecting individual control issues to wider systems, business strategy, and long-term assurance.

You do not need to master all of these at once. Treat the list as a map of future growth areas:

• Enterprise risk management
• Control design
• Security architecture risk review
• Cloud risk
• Privacy engineering
• Third-party risk at scale
• Regulatory interpretation
• Board-level reporting
• Quantitative risk analysis
• Security assurance programs
• Compliance automation
• AI governance
• Global standards
• Mergers and acquisitions risk
• Advanced audit management

In mature programs, GRC is not just about passing audits.

It is about enabling business safely at scale. That means security should support good decisions instead of becoming a blocker people work around.

30. What Senior GRC Professionals Do Differently

Seniority in GRC is not just knowing more frameworks. It is seeing patterns earlier and fixing root causes instead of chasing the same finding every quarter.

A junior says:

"This control failed."

An intermediate says:

"This control failed and should be remediated."

A senior says:

"This control failed because ownership and process design are weak. The risk affects customer trust and regulatory exposure. We need a sustainable operating model, not a one-time fix."

Senior professionals think in systems.

They ask:

• Why did the control fail?
• Is this isolated or systemic?
• Is ownership clear?
• Is the process scalable?
• Is the evidence reliable?
• Is the risk accepted by the right person?
• Is management seeing the right information?
• Are we reducing real risk or only passing audits?

This is the mindset to practice even as a beginner: do the immediate task, but keep asking what process allowed the problem to happen.

31. Intermediate Roadmap

This roadmap is a practical study plan. Adjust the pace if you are balancing school, work, or other courses. The goal is steady practice, not rushing through a checklist.

Month 1

Focus:

• Risk register
• Risk statements
• Control types
• Evidence quality
• Access review

Practice:

• Build a sample risk register.
• Write 10 risk statements.
• Review sample user access data.

Month 2

Focus:

• Vendor risk
• Policy management
• Audit readiness
• Vulnerability risk

Practice:

• Create vendor questionnaire.
• Write an access control policy.
• Map vulnerabilities to business risk.

Month 3

Focus:

• Framework mapping
• Incident response evidence
• Metrics and reporting
• Executive communication

Practice:

• Map 10 controls to NIST CSF and ISO 27001.
• Build a monthly GRC dashboard.
• Write an executive summary for top 5 risks.

32. Portfolio Projects

To prove your GRC skills, create small artifacts that look like real work products. They do not need to be perfect, but they should be clear, organized, and defensible.

1. Sample risk register
2. Access review test file
3. Vendor risk questionnaire
4. Information security policy
5. Incident response checklist
6. Audit evidence tracker
7. Control matrix mapped to NIST CSF
8. Monthly GRC dashboard
9. Vulnerability risk report
10. Business continuity checklist

Small Practice Task

Pick one issue, such as missing MFA for admin accounts or a vendor with no security review. Write a risk statement, choose likelihood and impact, name the owner, list the evidence you would request, and decide whether the treatment should be mitigate, accept, transfer, or avoid.

For each project, include a short note explaining the scenario, assumptions, evidence used, and what decision the artifact supports. That makes the project easier to discuss in interviews and job applications.

33. Final Intermediate Summary

Intermediate GRC is about applying structure to security problems. You are learning to turn unclear issues into decisions people can understand, own, track, and prove.

You should be able to:

• Identify and write risks clearly
• Build and maintain a risk register
• Test controls
• Collect strong evidence
• Prepare for audits
• Review vendors
• Track exceptions
• Communicate with business owners
• Translate technical issues into business risk
• Support compliance without becoming a checkbox person

The core professional habit:

Always connect technical facts to business risk, ownership, evidence, and decision-making.

This is the bridge from foundation to professional GRC. If you can explain the risk, identify the owner, request the right evidence, and track the decision honestly, you are already practicing the core of real GRC work.