GRC Foundation Guide

1. What Is GRC?

GRC stands for:

• Governance
• Risk Management
• Compliance

In simple terms:

GRC is how an organization decides what security should be done, why it matters, who is responsible, how risk is measured, and how evidence is shown to prove things are being done.

Technical cybersecurity asks:

"Is this system secure?"

GRC asks:

"Is this system secure enough for the business risk, legal requirements, customer expectations, and company policy?"

2. Governance

Governance is about direction, ownership, rules, and accountability.

It answers:

• Who owns security?
• Who approves policies?
• Who accepts risk?
• Who is responsible when controls fail?
• What security standards must teams follow?
• How does leadership know security is working?

Example

A company says:

"All employees must use MFA for company email."

That is a governance decision.

Then IT or security teams implement MFA.

Then GRC checks:

• Is there a policy?
• Who approved it?
• Is MFA enabled for everyone?
• Are exceptions documented?
• Is there evidence?

3. Risk Management

Risk management is the process of identifying, analyzing, treating, and monitoring risk.

A useful beginner model is:

Risk = Threat x Vulnerability x Impact

This is a thinking aid, not a universal calculation. Organizations define their own risk methods, scales, and scoring rules.

Example

An attacker tries phishing.

• Threat: Phishing attacker
• Vulnerability: Employees lack MFA or awareness
• Impact: Email compromise, data theft, fraud

So the risk is:

Business email compromise due to phishing.

Common Risk Treatment Options

When a risk is identified, an organization usually chooses one of four actions:

4. Compliance

Compliance means meeting required rules.

These rules may come from:

• Laws
• Regulations
• Industry standards
• Customer contracts
• Internal policies
• Security frameworks

Compliance asks:

"Can we prove we are following the required rules?"

Examples

A company may need to meet different kinds of obligations and assurance expectations:

• Laws and regulations: GDPR, HIPAA, and local data protection laws
• Industry or contractual requirements: PCI DSS and customer security clauses
• Certifiable standards: ISO/IEC 27001
• Independent assurance reports: SOC 2 examinations
• Voluntary frameworks and guidance: NIST Cybersecurity Framework
• Customer due diligence: Security questionnaires and evidence requests

For Nepali companies, compliance may also involve:

• Nepal Rastra Bank requirements for banks and financial institutions
• Data privacy expectations
• Customer or vendor security requirements
• Internal audit requirements
• International client requirements if outsourcing or providing IT services abroad

5. GRC vs Technical Security

GRC does not replace technical security. It connects technical security to business decisions.

Technical View

"There is no MFA on admin accounts."

GRC View

"Lack of MFA on admin accounts increases the likelihood of unauthorized access to critical systems. This creates high business risk. The recommended control is mandatory MFA for all privileged users."

Senior GRC View

"This control gap exposes the company to account takeover, regulatory scrutiny, customer trust loss, and possible financial loss. Management must either fund remediation, define a timeline, or formally accept the risk."

6. Important GRC Terms

Asset

Anything valuable to the organization.

Examples:

• Customer data
• Servers
• Laptops
• Source code
• Payment systems
• Email accounts
• Cloud infrastructure
• Reputation

Threat

Something that can cause harm.

Examples:

• Hackers
• Malware
• Insider misuse
• Natural disaster
• Human error
• Vendor compromise

Vulnerability

A weakness that can be exploited.

Examples:

• Weak passwords
• Unpatched systems
• No backups
• Public S3 bucket
• Poor access control

Control

A safeguard that reduces risk.

Examples:

• MFA
• Firewalls
• Backups
• Security awareness training
• Logging
• Access reviews
• Encryption

Risk

The possibility of loss or harm.

Example:

Unauthorized access to customer data due to weak access controls.

Inherent Risk

Risk before controls are applied.

Residual Risk

Risk remaining after controls are applied.

Risk Owner

The person responsible for managing or accepting a risk.

Usually this is a business leader, system owner, department head, or executive.

Control Owner

The person responsible for operating a control.

Example:

• IT manager owns patching control.
• HR owns onboarding/offboarding process.
• Security team owns SIEM monitoring.

7. Types of Controls

Controls are usually grouped into three types.

Administrative Controls

Policies, procedures, training, and governance.

Examples:

• Security policy
• Acceptable use policy
• Risk management procedure
• Security awareness training
• Vendor review process

Technical Controls

Technology-based safeguards.

Examples:

• MFA
• EDR
• Firewall
• SIEM
• Encryption
• Access control
• Vulnerability scanning

Physical Controls

Physical protection.

Examples:

• CCTV
• Locks
• Biometric access
• Visitor logs
• Security guards
• Server room access control

8. Preventive, Detective, and Corrective Controls

Controls can also be grouped by purpose.

Preventive Controls

Stop bad things before they happen.

Examples:

• MFA
• Firewall rules
• Secure configuration
• Access restrictions

Detective Controls

Detect bad things when they happen.

Examples:

• SIEM alerts
• Log monitoring
• IDS
• File integrity monitoring

Corrective Controls

Help recover after something bad happens.

Examples:

• Backups
• Incident response
• Password reset
• Disaster recovery plan

9. Policies, Standards, Procedures, and Guidelines

These are often confused.

Policy

A high-level rule approved by management.

Example:

All users must use strong authentication to access company systems.

Standard

A specific mandatory requirement.

Example:

Passwords must be at least 12 characters and MFA must be enabled.

Procedure

Step-by-step instructions.

Example:

How to disable an employee account after resignation.

Guideline

Recommended practice, usually not mandatory.

Example:

Employees should avoid using public Wi-Fi without VPN.

10. Risk Assessment Basics

A risk assessment identifies and evaluates risks.

Basic steps:

1. Identify assets.
2. Identify threats.
3. Identify vulnerabilities.
4. Estimate likelihood.
5. Estimate impact.
6. Determine risk rating.
7. Recommend treatment.
8. Assign owner.
9. Track remediation.

Simple Risk Rating

Example Risk

11. Control Testing Basics

Control testing checks whether a control exists and works.

Example Control

All terminated employees must have access removed within 24 hours.

Evidence to Test

• HR termination list
• IAM logs
• Ticket records
• Account disable timestamps

Testing Question

Were all terminated users disabled within 24 hours?

Result

• Pass: All accounts disabled on time.
• Fail: Some accounts remained active.
• Partial: Most disabled, but process inconsistent.

12. Evidence

Evidence is proof.

In GRC, evidence is everything.

Examples:

• Screenshots
• Logs
• Tickets
• Reports
• Meeting minutes
• Signed policies
• Configuration exports
• Access review records
• Vulnerability scan results
• Training completion reports

Good evidence should be:

• Clear
• Dated
• Relevant
• Traceable
• Complete
• From a reliable source

Bad evidence:

• Cropped screenshots with no date
• Verbal confirmation only
• Old reports
• Unclear ownership
• Evidence unrelated to the control

13. Common Frameworks

ISO 27001

A global standard for information security management systems.

Focus:

• Governance
• Risk management
• Security controls
• Continuous improvement

NIST Cybersecurity Framework

A practical framework organized around six functions in NIST CSF 2.0:

• Govern
• Identify
• Protect
• Detect
• Respond
• Recover

SOC 2

Common for technology and SaaS companies.

SOC 2 is an independent attestation report, not a certification. It evaluates controls against applicable trust services criteria:

• Security
• Availability
• Confidentiality
• Processing integrity
• Privacy

PCI DSS

Required for organizations handling payment card data.

Focus:

• Cardholder data protection
• Network security
• Access control
• Monitoring
• Vulnerability management

14. GRC Mindset

A beginner asks:

"Is this secure?"

A GRC professional asks:

"What is the risk, what control reduces it, who owns it, what evidence proves it, and what happens if we do not fix it?"

This mindset is extremely important.

Every issue should connect to:

• Business impact
• Risk
• Control
• Owner
• Evidence
• Timeline
• Decision

15. Example: Missing MFA

Technical Finding

Admin users do not have MFA enabled.

Risk Statement

There is a risk of unauthorized privileged access due to lack of MFA on administrator accounts, which could lead to data breach, service disruption, or unauthorized system changes.

Control Recommendation

Enable MFA for all privileged accounts.

Evidence Required

• List of admin accounts
• MFA configuration screenshot
• IAM policy
• Access review report

Risk Owner

Head of IT or system owner.

Status

Open until MFA is enabled and verified.

16. Example: No Backup Testing

Technical Finding

Backups exist, but restoration has not been tested.

Risk Statement

There is a risk that the organization may not be able to recover critical systems during ransomware, hardware failure, or accidental deletion because backup restoration has not been tested.

Control Recommendation

Perform quarterly backup restoration testing.

Evidence Required

• Backup schedule
• Restore test report
• Screenshots or logs
• Issues found
• Approval/sign-off

17. Common GRC Documents

A GRC analyst often works with:

• Information security policy
• Risk register
• Asset inventory
• Control matrix
• Audit report
• Compliance checklist
• Vendor assessment
• Incident response plan
• Business continuity plan
• Disaster recovery plan
• Access review evidence
• Vulnerability management report

18. Risk Register Basics

A risk register is a list of risks.

Basic columns:

Example

19. How GRC Supports SOC

Your SOC knowledge helps GRC a lot.

SOC sees alerts.

GRC asks:

• Are alerts reviewed on time?
• Is there an incident response process?
• Are incidents documented?
• Are lessons learned tracked?
• Are monitoring controls mapped to risk?
• Is evidence retained?

Example:

SOC detects brute-force attempts.

GRC connects that to:

• Access control policy
• Logging control
• Incident response process
• MFA requirement
• Risk register
• Audit evidence

20. Beginner Practice Tasks

Task 1: Write a Risk Statement

Finding:

Employees use weak passwords.

Write a risk statement:

There is a risk of unauthorized access due to weak employee passwords, which could lead to account compromise, data exposure, or misuse of company systems.

Task 2: Identify Evidence

Control:

MFA is enabled for all users.

Evidence:

• MFA report from identity provider
• Screenshot of MFA policy
• User list showing MFA status
• Exception list

Task 3: Map Control Type

Control:

Security awareness training.

Answer:

• Administrative control
• Preventive control

21. What You Should Know Before Moving to Intermediate

Before moving forward, you should be comfortable explaining:

• Governance, risk, and compliance
• Difference between risk and control
• Difference between policy, standard, procedure, and guideline
• What a risk register is
• What evidence is
• What control testing means
• Basic risk rating
• Basic frameworks like ISO 27001, NIST CSF, SOC 2, and PCI DSS
• How SOC evidence supports GRC

22. Foundation-Level Interview Questions

Question 1

What is GRC?

Good answer:

GRC stands for Governance, Risk, and Compliance. It helps organizations define security rules, manage risks, meet legal or regulatory requirements, and prove controls are working through evidence.

Question 2

What is the difference between a risk and a control?

Good answer:

A risk is something that could cause harm. A control is a safeguard used to reduce that risk.

Question 3

What is a risk register?

Good answer:

A risk register is a document used to track identified risks, their ratings, owners, treatment plans, due dates, and status.

Question 4

Why is evidence important?

Good answer:

Evidence proves that a control exists and is operating effectively. Without evidence, compliance cannot be demonstrated.

23. Foundation Summary

GRC is not just paperwork.

Good GRC helps organizations:

• Understand risk
• Make better decisions
• Protect important assets
• Meet compliance obligations
• Prove security controls work
• Communicate clearly with leadership
• Avoid unnecessary business damage

The foundation mindset:

Identify the risk, connect it to business impact, recommend a control, assign ownership, collect evidence, and track progress.

24. Next Step

After this foundation, move to intermediate GRC.

At intermediate level, you should learn how to:

• Build a risk register
• Perform control testing
• Prepare for audits
• Review vendors
• Map controls to frameworks
• Write professional risk statements
• Communicate with management
• Support real business decisions