Governance, Risk, and Compliance (GRC) - Comprehensive Guide
Why GRC Matters - The Real World Context
The Billion Dollar Question
In 2023, a major US healthcare provider paid $4.5 million in HIPAA fines for failing to conduct a risk assessment. In 2024, Irish Data Protection Commission fined Meta €91 million for GDPR violations related to password storage. These aren't just numbers - they represent real business failures that could have been prevented.
Here's the reality: You can be the best penetration tester in the world, find every vulnerability, write perfect firewall rules, and detect every intrusion - but if your organization doesn't have proper governance, doesn't understand its risks, and isn't compliant with regulations, you will fail.
The Technical vs. Business Security Gap
As cybersecurity professionals with red team and blue team experience, you understand:
How to exploit vulnerabilities (red team thinking)
How to detect and respond to attacks (blue team operations)
How malware works and how to analyze it
But here's what you might not yet fully grasp:
Technical Scenario:
You discover a critical SQL injection vulnerability in the company's payment system
You write a detailed report with PoC, CVSS score 9.8
You submit it to the development team
...and nothing happens for 6 months
Why? Because there's no governance structure defining who is responsible, no risk assessment showing the business impact, and no compliance requirement forcing action.
GRC Scenario:
Same vulnerability discovered
Risk assessment shows potential PCI-DSS violation (business cannot process cards without compliance)
Governance policy states "Critical vulnerabilities must be patched within 72 hours"
Compliance team escalates to CISO who has authority and budget
...vulnerability fixed in 48 hours
This is why GRC matters. It's the bridge between technical security and business reality.
GRC cheatsheet - brief presentation of most important information:
The GRC Triangle - Understanding the Interconnections
How They Work Together
Think of GRC as a three-legged stool:
Governance = The rules of the game
"Who decides what gets protected and how?"
"What's our security strategy?"
"Who has authority and budget?"
Risk = The prioritization engine
"What should we protect first?"
"How much should we spend on security?"
"What's the likelihood and impact?"
Compliance = The proof and accountability
"Can we prove we're doing what we said we'd do?"
"Are we meeting legal requirements?"
"What happens if we fail?"
Real-World Example: The Data Breach Chain
Let's trace how poor GRC leads to disaster:
Bad Governance:
No clear policy on data classification
IT department and Security team don't communicate
No one knows who "owns" customer data
Ignored Risk:
No risk assessment performed on customer database
Database contains 5 million credit card numbers (high value asset)
Database accessible from internet with weak password (high likelihood)
Risk = CRITICAL, but no one calculated it
Failed Compliance:
Company stores full PAN (Primary Account Number) in plaintext
Direct violation of PCI-DSS Requirement 3.4
No one checked compliance before going live
Result:
Database breached in 3 hours
5 million cards stolen
Company loses PCI compliance → cannot process cards → business stops
GDPR fine: €20 million
PCI fine: $500,000/month until compliant
Reputation destroyed
Total cost: Company bankrupt in 6 months
With proper GRC:
Governance: Clear data ownership, security policies mandated by CISO
Risk: Risk assessment identifies critical risk → triggers immediate mitigation
Compliance: PCI-DSS requirements checked before deployment → encryption mandated
Result: Breach prevented, business thrives
Governance - The Strategic Foundation
What Governance Really Means
Governance isn't about technical controls - it's about decision-making authority and strategic direction.
Think of it this way:
Red Team thinking: "How can I break this?"
Blue Team thinking: "How can I detect and stop this?"
Governance thinking: "Should we even build this? Who decides? Who pays? Who's accountable?"
The Policy Hierarchy - Making Strategy Actionable
One of the most misunderstood aspects of governance is how high-level strategy becomes day-to-day action. This is where the policy hierarchy becomes critical.
Practical Example: Password Security
Let's see how this hierarchy works in practice:
Level 1: Business Strategy "Our company must protect customer trust and prevent unauthorized access to systems"
Level 2: Policy (WHY) "All company systems must implement authentication controls to prevent unauthorized access. This policy applies to all employees, contractors, and systems."
Characteristics: High-level, mandatory, approved by senior management
Audience: Everyone in the organization
Frequency: Reviewed annually or after major incidents
Level 3: Standard (WHAT) *"User passwords must meet the following requirements:
Minimum 16 characters
Complexity: mix of uppercase, lowercase, numbers, symbols
Cannot reuse last 12 passwords
Must change every 90 days: no (this is outdated feature)
Multi-factor authentication (MFA) required for all remote access"*
Characteristics: Specific, measurable, technical
Audience: System administrators, developers
Frequency: Updated based on threat landscape
Level 4: Procedure (HOW) *"To configure Active Directory password policy:
Open Group Policy Management
Navigate to Default Domain Policy
Edit: Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy
Set minimum password length = 16
Enable password complexity requirements
Set password history = 12
Click Apply..."*
Characteristics: Step-by-step instructions, screenshots
Audience: Specific technical role (AD admins)
Frequency: Updated when technology changes
Level 5: Guideline (RECOMMENDATIONS) "Consider using a password manager like 1Password or Bitwarden to generate and store complex passwords. While the minimum length is 16 characters, 20+ is recommended for sensitive systems."
Characteristics: Best practices, non-mandatory
Audience: End users
Frequency: Flexible
Why This Hierarchy Matters
Common Mistake #1: Writing procedures instead of policies
Wrong: "Employees must use the bcrypt() function with cost factor 16"
Right Policy: "All passwords must be stored using industry-standard cryptographic hashing"
Why: Technology changes, policies shouldn't
Common Mistake #2: Making guidelines mandatory
Leads to unenforceable rules and compliance confusion
Common Mistake #3: No clear hierarchy
Result: No one knows what's mandatory vs. optional
Example: "It is recommended that all passwords be changed monthly" - Is this required or not?
Governance Roles and Responsibilities
Understanding WHO makes decisions is crucial:
Key Roles:
Board of Directors / Executive Management
Sets overall risk appetite
Approves major security investments
Accountable for major breaches
CISO (Chief Information Security Officer)
Defines security strategy
Manages security budget
Reports risk to executives
Not necessarily technical - more business/risk focused
Data Protection Officer (DPO) (Required by GDPR for some orgs)
Independent advocate for privacy
Monitors GDPR compliance
Acts as contact point for authorities
Must be independent - cannot report to IT or have conflicts of interest
Security Governance Committee
Reviews and approves policies
Prioritizes security initiatives
Cross-functional (IT, Legal, HR, Business units)
System Owners
Responsible for specific systems/applications
Makes risk decisions for their systems
Often business managers, not technical staff
Security Operations (Your likely role)
Implements technical controls
Executes procedures
Reports on effectiveness
The NIST Cybersecurity Framework (CSF) 2.0
The CSF is the most widely adopted governance framework globally. Let's understand why it's so popular and how to use it.
The 6 Functions - Your Security Program Blueprint
GOVERN (GV) - Added in CSF 2.0, previously implicit
This is the "brain" - it oversees and directs everything else.
What it covers:
Organizational context and cybersecurity strategy (GV.OC)
Risk management strategy (GV.RM)
Roles, responsibilities, and authorities (GV.RR)
Policy creation and oversight (GV.PO)
Cybersecurity supply chain risk management (GV.SC)
Real-world example: A company using CSF starts here:
Board approves cybersecurity strategy aligned with business goals
CISO creates risk management framework
Policies written based on risk priorities
All other functions (Identify, Protect, etc.) follow from these decisions
IDENTIFY (ID)
"You can't protect what you don't know you have"
Key categories:
Asset Management (ID.AM): Hardware, software, data inventory
Risk Assessment (ID.RA): Understanding threats and vulnerabilities
Improvement (ID.IM): Lessons learned and continuous enhancement
Why this matters for you: As a pentester/SOC analyst, you need accurate asset inventories to:
Know what systems to test/monitor
Understand data flows
Identify critical assets vs. low-value targets
Common failure: Companies skip this step and build security on guesswork
Result: Protecting wrong things, missing critical assets
PROTECT (PR)
Technical and administrative controls to prevent incidents.
Key categories:
Identity Management & Access Control (PR.AA)
Awareness and Training (PR.AT)
Data Security (PR.DS)
Platform Security (PR.PS) - formerly "Protective Technology"
Technology Infrastructure Resilience (PR.IR)
Mapping to your knowledge:
Red team: These are the controls you try to bypass
Blue team: These are the controls you implement and tune
Example: MFA (Multi-Factor Authentication)
Governance: Policy requires MFA
Standard: MFA required for all remote access
Protect function: PR.AA-05 "Authenticators are managed by the organization"
Your job: Configure Duo/Okta/Azure MFA, ensure enrollment
DETECT (DE)
Your SOC/Blue Team home.
Key categories:
Continuous Monitoring (DE.CM)
Adverse Event Analysis (DE.AE)
Critical connection to blue team:
This is where SIEM, IDS/IPS, EDR live
Log collection → Analysis → Alerts → Investigation
CSF provides the "why" for your SIEM rules
Example:
CSF Subcategory: DE.CM-01 "Networks are monitored to find potentially adverse events"
Your implementation: Suricata/Snort IDS rules, network flow analysis
Governance link: Monitoring policy requires 90-day log retention
RESPOND (RS)
Incident response - what to do when (not if) you're breached.
Key categories:
Incident Management (RS.MA)
Incident Analysis (RS.AN)
Incident Response Reporting and Communication (RS.CO)
Incident Mitigation (RS.MI)
Why governance matters here: Without governance, you might:
Not know who has authority to shut down production systems
Not know when to call law enforcement
Not know if you can legally analyze the malware sample
Not know who communicates with customers/press
Example decision tree:
RECOVER (RC)
Getting back to business after an incident.
Key categories:
Incident Recovery Plan Execution (RC.RP)
Incident Recovery Communication (RC.CO)
Connection to risk:
RTO (Recovery Time Objective): How fast must we recover?
RPO (Recovery Point Objective): How much data loss is acceptable?
These are risk decisions made during governance, not technical decisions
Example:
Business: "We cannot afford more than 4 hours of downtime on e-commerce"
Risk assessment: 4-hour outage = €500k revenue loss
Governance decision: Invest €200k in redundant infrastructure
Recovery procedure: Your job to implement and test the DR plan
How to Actually Use CSF
Step 1: Current State Assessment Map your existing controls to CSF categories
"We have a firewall" → PR.PS-04 (Protect Platform Security)
"We monitor logs in SIEM" → DE.CM-01 (Detect Continuous Monitoring)
Step 2: Target State Definition Based on risk, decide where you need to be
"We're currently at Tier 1 (Partial) for DE.CM, need to get to Tier 3 (Repeatable)"
Step 3: Gap Analysis Identify what's missing
"We don't have DE.AE-02 (Adverse event analysis), need to implement investigation procedures"
Step 4: Prioritize & Implement Use risk assessment to prioritize gaps
High-risk gaps first, low-risk gaps later
Step 5: Measure & Improve Create metrics to track progress
"95% of critical systems have MFA (PR.AA-05)" - good
"Only 40% have MFA" - gap to close
CSF Implementation Tiers
CSF defines 4 maturity levels for implementing each function:
Tier 1: Partial
Ad hoc, reactive
No formal processes
Example: "We patch when we remember"
Tier 2: Risk Informed
Some risk awareness
Processes not formalized
Example: "We patch critical systems based on severity"
Tier 3: Repeatable
Formal, documented processes
Regular updates
Example: "We have documented patch management procedure, run monthly"
Tier 4: Adaptive
Continuously improving
Predictive, proactive
Example: "We use threat intelligence to prioritize patching, automate deployment, measure effectiveness"
Important: You don't need Tier 4 for everything. A small company might be:
Tier 4 for PROTECT (core business)
Tier 2 for RECOVER (acceptable risk)
This is a governance decision based on risk appetite
Risk Management - The Heart of Cybersecurity
Understanding Risk: The Formula That Drives Decisions
Here's the fundamental concept that drives everything in cybersecurity:
Let's break this down with a real scenario:
Scenario: Public Website with Customer Database
Asset Value:
Website itself: €50k to rebuild
Customer database: 100,000 email addresses
Reputation impact: Immeasurable but significant
Threat:
Script kiddies scanning for vulnerabilities (common)
Competitors wanting customer list (less common)
Nation-state actors (unlikely for small business)
Vulnerability:
Unpatched WordPress plugin with known SQL injection
CVSS Score: 9.8 (Critical)
Public exploit available on ExploitDB
Likelihood:
Known vulnerability + public exploit + automated scanners = HIGH
"When, not if"
Impact:
Data breach → GDPR fine (up to €20M or 4% revenue)
Customer notification costs
Reputation damage
Legal fees
Total estimated impact: €500k for small company
Risk Calculation:
High likelihood × High impact = CRITICAL RISK
Action required: Immediate remediation
The Risk Assessment Process
Qualitative vs Quantitative Risk Analysis
Qualitative Analysis (Most common)
Uses descriptive scales: Low, Medium, High, Critical
Risk Matrix Example:
Advantages:
Fast, easy to understand
Works when you don't have precise data
Good for communicating with non-technical stakeholders
Disadvantages:
Subjective ("What's 'high' to you vs. me?")
Hard to prioritize multiple "high" risks
Difficult to justify budget
Quantitative Analysis (More sophisticated)
Uses actual numbers (€) to calculate expected losses.
Key Metrics:
SLE (Single Loss Expectancy)
How much money do you lose if this risk happens once?
Example:
Asset: Server worth €10,000
Exposure Factor: 100% (server completely destroyed by ransomware)
SLE = €10,000 × 1.0 = €10,000
ARO (Annualized Rate of Occurrence) How many times per year will this happen?
Examples:
Ransomware attack: 0.1 (once every 10 years)
Phishing attempt: 365 (daily)
Natural disaster: 0.01 (once per 100 years)
ALE (Annualized Loss Expectancy)
How much do you expect to lose per year from this risk?
Example:
SLE = €10,000
ARO = 0.1
ALE = €10,000 × 0.1 = €1,000/year
This is the number that justifies security spending:
ALE = €1,000/year from ransomware
Backup solution costs = €500/year
ROI: Positive! Spend €500 to avoid €1,000 loss
Practical Risk Assessment Example
Let's assess risk for a realistic scenario:
Company: Small e-commerce business (50 employees) Asset: Customer database with credit card data Value: 50,000 customers, potential GDPR fine €2M, PCI fine €500k, reputation damage €1M = €3.5M total
Risk #1: SQL Injection on Payment Page
Vulnerability: Found in pentest, CVSS 9.1
Threat: Automated bots constantly scanning
Likelihood: High (public exploits exist)
Impact: Severe (lose all card data)
Qualitative: CRITICAL
Quantitative:
SLE = €3.5M × 0.8 (not all data compromised) = €2.8M
ARO = 0.3 (once every 3 years given automation)
ALE = €2.8M × 0.3 = €840,000/year
Risk Response Decision:
Cost to fix SQLi: €10,000 (developer time)
Cost to implement WAF: €20,000/year
Total: €30k to avoid €840k = OBVIOUS YES
Risk #2: Physical Theft of Office Laptops
Vulnerability: No full disk encryption
Threat: Burglary (office in high-crime area)
Likelihood: Medium (burglaries reported monthly in area)
Impact: Moderate (some customer data on laptops, but not full DB)
Qualitative: HIGH
Quantitative:
SLE = €100,000 (GDPR fine for unencrypted devices) + €5,000 (laptop value) = €105k
ARO = 0.2 (once every 5 years)
ALE = €105k × 0.2 = €21,000/year
Risk Response Decision:
Cost to implement BitLocker/FileVault: €0 (built-in OS feature)
Time to deploy: 2 hours × 50 devices = 100 hours = €5,000
Total: €5k one-time to avoid €21k/year = OBVIOUS YES
Risk #3: CEO Email Compromise
Vulnerability: CEO doesn't use MFA, predictable password pattern
Threat: BEC (Business Email Compromise) attackers
Likelihood: Medium (BEC is common)
Impact: Major (can approve fraudulent wire transfers)
Qualitative: HIGH
Quantitative:
SLE = €200,000 (average BEC loss)
ARO = 0.1 (BEC attempts are common, but success rate low)
ALE = €200k × 0.1 = €20,000/year
Risk Response Decision:
Cost to implement MFA: €10/user/month × 12 months = €6,000/year
Training cost: €2,000
Total: €8k to avoid €20k = YES
The Four Risk Response Strategies
Understanding these is crucial because not all risks should be "fixed":
1. MITIGATE (Reduce) Implement controls to reduce likelihood or impact
Examples:
Install firewall (reduce likelihood of network intrusion)
Implement backups (reduce impact of ransomware)
Deploy MFA (reduce likelihood of account compromise)
Cost vs. Benefit:
Control cost < ALE = Good investment
Control cost > ALE = Consider other options
2. TRANSFER (Share) Shift the financial burden to another party
Examples:
Cyber Insurance: Pay €50k/year premium to cover potential €5M breach
Cloud Provider: AWS responsible for physical security, power, network
Outsourced SOC: MSSP responsible for 24/7 monitoring
Important: Transfer of risk ≠ Transfer of liability
You still have legal obligations (GDPR, PCI-DSS)
Your customers still blame you if your cloud provider fails
Insurance doesn't prevent the breach, only pays for cleanup
3. ACCEPT Consciously decide to live with the risk
When to accept:
Risk level is Low
Cost of mitigation > potential loss
Risk is unavoidable (meteor strike)
Critical rules:
Must be documented - "We accept risk of [X] because [Y]"
Must be approved - By appropriate authority level (CISO, Board)
Must be re-assessed - Regularly, as threats change
Example:
Risk: Old WordPress blog gets defaced
Impact: Low (not main site, no customer data)
Cost to maintain/update: €10k/year
Decision: Accept the risk, shut it down if defaced
4. AVOID Stop doing the activity that causes risk
Examples:
Don't store credit card data → use payment processor (Stripe, PayPal)
Don't collect personal data if not needed → avoid GDPR obligations
Shut down vulnerable legacy system → eliminate attack surface
Best example:
Old application with unfixable vulnerabilities
Cost to secure > value it provides
Solution: Decommission it - risk goes to zero
Third-Party Risk Management (TPRM)
Modern companies don't operate in isolation. Your security is only as strong as your weakest vendor.
The Supply Chain Problem:
Real-world disaster: Target Breach (2013)
Target (retailer) had good security
HVAC vendor (Fazio Mechanical) had weak security
Attackers compromised HVAC vendor
Used vendor access to Target's network
Stole 40 million credit cards
Cost: $290 million to Target
Key lesson: Your vendors' security problems become your security problems.
TPRM Process
Phase 1: Vendor Assessment (Before signing contract)
Send security questionnaire covering:
Do you have ISO 27001 or SOC 2 certification?
Do you encrypt data at rest and in transit?
Do you perform penetration testing?
What's your incident response plan?
What data of ours will you have access to?
Where is data stored (which countries)?
Do you have cyber insurance?
Risk rating:
Critical vendors: Have access to crown jewels (payment processor, cloud provider)
High vendors: Have sensitive data access
Medium vendors: Limited data access
Low vendors: No data access (e.g., office coffee supplier)
Phase 2: Contractual Requirements
Security clauses to include:
Right to audit their security
Breach notification within 24-72 hours
Compliance with applicable regulations (GDPR, PCI-DSS)
Data deletion after contract ends
Minimum security controls (encryption, MFA, etc.)
Liability terms
Phase 3: Continuous Monitoring
Don't just assess once and forget:
Annual security reassessment
Monitor for breaches (use services like SecurityScorecard, BitSight)
Review their SOC 2 reports
Track their security posture over time
Phase 4: Incident Response Planning
Have a plan for when (not if) a vendor is breached:
Who do they contact immediately?
What data might be compromised?
What's our response plan?
How do we contain the damage?
The Risk Management Framework (RMF)
For large organizations and government, NIST provides a formal process: NIST SP 800-37 Risk Management Framework
Step 1: PREPARE
Assign roles (System Owner, ISSO, Authorizing Official)
Define organizational risk tolerance
Establish risk management strategy
Step 2: CATEGORIZE Using FIPS 199, categorize system impact:
Each dimension rated Low, Moderate, or High:
Low: Limited adverse effect
Moderate: Serious adverse effect
High: Severe or catastrophic adverse effect
Example: E-commerce Website
Confidentiality: HIGH (customer payment data)
Integrity: HIGH (orders must be accurate)
Availability: MODERATE (short outage acceptable)
System Categorization: HIGH
Example: Public Marketing Website
Confidentiality: LOW (all info public)
Integrity: MODERATE (defacement is embarrassing)
Availability: LOW (not critical)
System Categorization: LOW
Step 3: SELECT Controls
Based on categorization, select baseline from NIST SP 800-53 (1000+ controls):
LOW system: ~130 controls
MODERATE system: ~240 controls
HIGH system: ~350 controls
Example controls:
AC-2: Account Management
IA-5: Authenticator Management
SC-7: Boundary Protection
SI-4: System Monitoring
Step 4: IMPLEMENT Actually deploy the controls:
Configure firewalls (SC-7)
Set up MFA (IA-5)
Deploy SIEM (SI-4)
Document everything
Step 5: ASSESS Independent assessment team tests:
Are controls implemented correctly?
Are they effective?
Are there weaknesses?
Creates Security Assessment Report (SAR) with:
Pass/Fail for each control
Identified weaknesses
Recommendations
Step 6: AUTHORIZE
Authorizing Official (AO) - usually very senior (CIO, CISO, or higher):
Reviews all documentation
Reviews assessment results
Understands residual risks
Makes risk decision
Two possible outcomes:
Authority to Operate (ATO): "I accept the residual risk, system approved for 3 years"
Denial: "Risks too high, fix critical issues first"
This is a formal, documented, signed decision
Step 7: MONITOR Continuous monitoring:
Vulnerability scanning
Patch management
Configuration monitoring
Incident tracking
Annual re-assessment
If significant changes occur (new features, new threats), cycle back to Step 2
Compliance - Legal and Regulatory Landscape
The Compliance Ecosystem
Understanding the Difference: Laws vs Standards vs Frameworks
Laws/Regulations = Mandatory, backed by government
GDPR, NIS2, DORA
Criminal or financial penalties for violation
Apply to specific entities/sectors
Standards = Can be mandatory or voluntary
PCI-DSS (mandatory if you process cards)
ISO 27001 (voluntary, but often required by customers)
Certification possible
Frameworks = Voluntary guidance
NIST CSF, COBIT, ITIL
No penalties for not using
Organizations choose to adopt
GDPR - General Data Protection Regulation
What Makes GDPR So Powerful
Jurisdiction:
Protects all EU citizens/residents
Applies to ANY company worldwide processing EU data
Extraterritorial reach - US company with EU customers must comply
Enforcement:
€20 million OR 4% global annual revenue (whichever is higher)
Per violation, can be cumulative
Key Concepts and Terminology
Personal Data ANY information relating to an identified or identifiable person:
Obvious: Name, address, email, phone, ID numbers
Less obvious: IP address, cookie ID, location data, biometric data, online identifiers
Special categories (extra protection): Health, genetics, race, religion, political views, sexual orientation
Data Subject The individual person whose data you have
Your customer, employee, website visitor
Data Controller Determines the PURPOSE and MEANS of processing
"Why are we collecting data?"
"How will we use it?"
Example: E-commerce company collecting customer orders
Data Processor Processes data on behalf of controller
Cloud hosting provider (AWS, Azure)
Email marketing service (Mailchimp)
Payment processor (Stripe)
Important: Processor can still be fined for GDPR violations!
Data Protection Officer (DPO) Required if:
Public authority
Large-scale monitoring
Special categories of data processing
Must be independent, expert, properly resourced
GDPR Principles
1. Lawfulness, Fairness, Transparency
Must have legal basis for processing (consent, contract, legitimate interest, etc.)
Must be transparent about what you do with data
2. Purpose Limitation
Can only use data for stated purpose
Can't collect for one reason, then use for another
Example: Collect email for order confirmation → Can't use for marketing without separate consent
3. Data Minimization
Collect only what you NEED
Bad: "Enter your name, address, phone, date of birth, mother's maiden name" for a newsletter signup
Good: "Enter your email" for newsletter
4. Accuracy
Data must be accurate and up to date
Must provide way to correct errors
5. Storage Limitation
Don't keep data longer than necessary
Must define retention periods
Must delete after period expires
6. Integrity and Confidentiality
THIS IS WHERE CYBERSECURITY COMES IN
Protect data from unauthorized access, loss, destruction
Encryption, access controls, backups
7. Accountability
Controller must demonstrate compliance
Documentation is key
GDPR Article 32 - Security of Processing
This is the technical security article:
Required measures include:
Pseudonymization and encryption
Ability to ensure confidentiality, integrity, availability, resilience
Ability to restore availability after incident
Regular testing and assessment
Important: Not prescriptive - "appropriate to the risk"
Small blog: Basic security
Healthcare database: Strongest security
Your role as security professional:
Implement encryption (at rest: disk encryption; in transit: TLS)
Design resilient systems (high availability, backups)
Test systems (pentesting, DR drills)
Maintain logs for breach detection
Data Subject Rights
1. Right to be Informed
Privacy policy must explain everything
2. Right of Access
Subject can request copy of all their data
Must respond within 30 days
3. Right to Rectification
Fix wrong data
4. Right to Erasure ("Right to be Forgotten")
Delete data under certain conditions
Technical challenge: How do you delete from backups?
5. Right to Restrict Processing
"Stop using my data but don't delete it"
6. Right to Data Portability
Provide data in machine-readable format
Transfer to another controller
7. Right to Object
Object to processing (e.g., marketing)
8. Rights Related to Automated Decision Making
Protection against pure AI decisions
Data Breach Notification Requirements
72-Hour Rule: If breach likely to result in risk to rights and freedoms:
Notify supervisory authority within 72 hours of becoming aware
If later than 72 hours, must explain delay
Breach notification must include:
Nature of breach (what happened?)
Categories and number of affected individuals
Contact point (DPO)
Likely consequences
Measures taken/proposed
Individual Notification: If breach likely to result in high risk to individuals:
Must notify affected individuals without undue delay
Clear, plain language
Direct communication (email)
Penalties for late/missing notification:
Separate fine on top of breach fine
Can make total penalty worse
Real-World GDPR Penalties
Meta (Facebook) - €1.2 billion (2023)
Violation: Transferred EU data to US without proper safeguards
Lesson: International data transfers are risky
Amazon - €746 million (2021)
Violation: Improper processing of personal data
Lesson: Even tech giants aren't immune
Google - €90 million (2020)
Violation: Cookies without proper consent
Lesson: Cookie banners must be compliant
British Airways - €22 million (2020)
Violation: Data breach affecting 400,000 customers
Originally €204 million, reduced due to COVID impact
Lesson: Poor security = massive fines
Marriott - €18.4 million (2020)
Violation: Breach of Starwood guest database (500M records)
Lesson: Acquiring companies inherits data protection obligations
GDPR Compliance Checklist
Data Mapping:
Legal Basis:
Technical Security:
Processes:
Documentation:
PCI-DSS - Payment Card Industry Data Security Standard
What Makes PCI-DSS Different from GDPR
PCI-DSS is:
Industry standard, not law
Enforced through contracts with card brands
Extremely prescriptive (tells you exactly what to do)
Focused on ONE thing: protecting card data
GDPR is:
Law with criminal penalties
Principles-based (tells you goals, not always methods)
Covers all personal data
Both can apply: Credit card data is also personal data under GDPR!
Who Must Comply
Anyone who:
Accepts card payments
Processes card payments
Stores card data
Transmits card data
Merchant Levels (based on transaction volume):
Level 1: 6M+ transactions/year → Full audit required
Level 2: 1-6M transactions/year → Annual self-assessment
Level 3: 20k-1M e-commerce transactions/year → Self-assessment
Level 4: <20k e-commerce OR <1M total → Self-assessment
Key Terminology
Cardholder Data (CHD):
Primary Account Number (PAN) - the card number (16 digits)
Cardholder name
Expiration date
Service code
Sensitive Authentication Data (SAD): NEVER ALLOWED TO STORE AFTER AUTHORIZATION:
Full magnetic stripe data
CVV/CVC (3-4 digit code on back)
PIN
Cardholder Data Environment (CDE): The network segment where CHD is stored, processed, or transmitted
Must be isolated from rest of network
All PCI-DSS requirements apply here
Scope: What systems are in-scope for PCI-DSS?
Systems that store/process/transmit CHD
Systems that can impact security of CDE
Example: Firewall protecting CDE is in-scope
The 12 Requirements (6 Goals)
Requirement 3: Protect Stored Cardholder Data
3.1: Keep CHD storage to minimum
Don't store if you don't need to
Best practice: Don't store at all, use tokenization
3.2: Don't store SAD after authorization
NEVER store CVV, magnetic stripe, PIN
One violation = instant loss of ability to process cards
3.3: Mask PAN when displayed
Show only last 4 digits:
************1234Full PAN only for business need
3.4: Render PAN unreadable anywhere stored Options:
Strong cryptography (AES-256)
One-way hash (SHA-256 + salt)
Truncation (keep last 4 digits only)
Tokenization (replace PAN with random token)
As security professional: Your job is to scan for stored PANs:
Search database for 16-digit numbers
Search log files for card numbers
Search backup tapes
Use regex:
\b[0-9]{13,16}\bIf found in plaintext → critical finding
Requirement 4: Encrypt Transmission
All card data transmitted over public networks must be encrypted
Public networks:
Internet
Wireless networks
Cellular networks
Not just "outside your building" - includes wireless inside
Technical requirements:
TLS 1.2 or higher (TLS 1.0/1.1 deprecated)
Strong cipher suites only
Valid certificates from trusted CA
No self-signed certs for production
Common violations:
HTTP instead of HTTPS for payment forms
Emailing card numbers (email is plaintext)
Saving card data in Slack/Teams messages
Storing in cloud storage without encryption
Requirement 6: Secure Systems and Applications
6.3: Develop secure software
Security testing during development
Code review for vulnerabilities
Follow OWASP Top 10
6.5: Address common vulnerabilities
SQL injection
XSS (Cross-Site Scripting)
CSRF
Buffer overflows
This is where your red team knowledge applies!
6.6: Web application protection Two options:
Application layer firewall (WAF) before web app
Manual/automated vulnerability assessment at least annually
Requirement 8: Identify and Authenticate Access
8.3: Secure remote access
MFA required for all remote access to CDE
No exceptions
Includes VPN, admin access, etc.
8.4: MFA for all users
PCI-DSS v4.0 (current): MFA required for ALL access to CDE
Not just remote, includes local access
8.5: Multi-factor authentication
Something you know (password)
Something you have (token, phone)
Something you are (biometric)
Requirement 10: Log and Monitor
10.2: Audit trails for all access Must log:
User access to CHD
Actions by privileged users
Access to audit logs
Invalid access attempts
System changes
10.4: Log retention
Minimum 90 days readily available
Minimum 12 months total retention
10.7: Detect failures
Automated alerts for security failures
Example: IDS alerts, WAF blocks
Requirement 11: Test Security
11.3: External and internal penetration testing
Annually and after significant changes
By qualified internal staff or third party
Must test CDE and segmentation controls
11.4: Intrusion detection/prevention
Deploy IDS/IPS to monitor traffic
Alert on suspected compromise
11.5: Change detection
File integrity monitoring (FIM) on critical files
Alert on unauthorized modifications
PCI-DSS Compliance Process
Self-Assessment Questionnaire (SAQ): For smaller merchants, different SAQs based on environment:
SAQ A: Card-not-present, outsourced processing (easiest)
SAQ B: Imprint machines or standalone terminals
SAQ C: Payment apps connected to internet
SAQ D: All other merchants and service providers (most comprehensive)
Attestation of Compliance (AoC): Formal document stating you're compliant
Signed by executive
Submitted to acquirer/card brand
Valid for 1 year
Quarterly Network Scans: By PCI Approved Scanning Vendor (ASV)
External vulnerability scans
No high/critical vulnerabilities
Must pass 4 consecutive quarters
Penalties for Non-Compliance
Card Brand Fines:
€5,000 - €100,000 per month
Escalate if not remediated
Worst penalty:
Loss of ability to accept cards
Business-ending for many companies
Additional costs if breached:
Reissuing cards: €3-5 per card
Forensic investigation: €100k+
Brand reputation damage
Lawsuits
NIS2 Directive - Network and Information Security
What is NIS2?
Full name: Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union
Purpose:
Strengthen cybersecurity requirements across EU
Replace original NIS Directive (2016)
Harmonize security standards across member states
Key dates:
Adopted: December 2022
Member states must implement: October 2024
Companies must comply: By October 2024
Why NIS2 Matters
Broader scope than GDPR:
GDPR: Focuses on personal data
NIS2: Focuses on critical infrastructure and services
Many companies subject to both
Sector-based approach: Essential and important sectors must comply
Who Must Comply with NIS2?
Size criteria:
Medium enterprises: 50-249 employees OR €10-50M turnover
Large enterprises: 250+ employees OR €50M+ turnover
Some small entities if critical
NIS2 Key Requirements
1. Risk Management Measures
Organizations must implement:
Risk analysis and security policies
Incident handling procedures
Business continuity (backup, DR)
Supply chain security (vendor assessment)
Security in acquisition and development
Vulnerability handling and disclosure
Encryption and cryptography
Personnel security (training, access control)
MFA and secure communication
Network security (firewalls, segmentation)
2. Incident Reporting
Must report significant incidents:
Early warning: Within 24 hours (initial notification)
Incident notification: Within 72 hours (detailed)
Final report: Within 1 month
What's a significant incident?
Has caused or can cause severe operational disruption
Has affected or can affect other EU states
Has caused or can cause material losses
3. Management Responsibility
Critical change from NIS1:
Management bodies are directly liable
Board members can be personally sanctioned
Must approve cybersecurity measures
Must oversee implementation
Must attend cybersecurity training
4. Supply Chain Security
Must assess cybersecurity of suppliers:
Due diligence before contracts
Security requirements in contracts
Regular assessment of supplier risks
Especially for ICT services
NIS2 Penalties
Maximum fines:
Essential entities: Up to €10M or 2% global annual turnover
Important entities: Up to €7M or 1.4% global annual turnover
Personal liability:
Management can be temporarily barred from positions
Criminal sanctions possible in some member states
Differences: NIS2 vs GDPR
Focus
Personal data protection
Critical infrastructure/services
Scope
Anyone processing personal data
Specific sectors
Penalty
Up to €20M or 4%
Up to €10M or 2%
Reporting
72 hours for data breaches
24-72 hours for incidents
Management
DPO recommended
Board directly responsible
Many companies must comply with BOTH
Practical Example: Energy Company
Company: Electricity distribution company (Essential sector under NIS2)
Must comply with:
GDPR: For customer billing data
NIS2: For grid operations and cybersecurity
Incident scenarios:
Scenario 1: Customer data breach
10,000 customer records stolen
GDPR: Report to DPA within 72 hours, notify customers
NIS2: May not be reportable if doesn't affect operations
Scenario 2: Ransomware on control systems
Grid monitoring systems encrypted
Potential power outage
GDPR: Report if personal data compromised
NIS2: MUST report within 24 hours (critical infrastructure)
Scenario 3: Supplier compromise
SCADA system vendor breached
Vendor has access to grid control systems
GDPR: Report if customer data affected
NIS2: MUST report, supplier risk is in scope
DORA - Digital Operational Resilience Act
What is DORA?
Full name: Regulation (EU) 2022/2554 on digital operational resilience for the financial sector
Purpose:
Strengthen ICT security in financial sector
Harmonize requirements across EU
Address cyber risks specifically for finance
Key dates:
Adopted: December 2022
Applies from: January 17, 2025
Direct regulation (no national implementation needed)
Why DORA Was Created
Problem identified: Financial sector heavily dependent on ICT:
Banks
Payment institutions
Investment firms
Insurance companies
Crypto-asset service providers
But:
Different rules in different EU countries
Third-party ICT providers not regulated
Operational resilience not standardized
Solution: DORA creates unified ICT risk framework
Who Must Comply with DORA?
Important: Even non-financial companies must comply if they provide critical ICT services to financial sector
DORA Five Pillars
1. ICT Risk Management
Must establish comprehensive ICT risk management framework:
Identification and assessment of ICT risks
Protection and prevention measures
Detection mechanisms
Response and recovery capabilities
Learning and evolving capabilities
Communication plans
Sound familiar? This maps to NIST CSF functions:
Identify, Protect, Detect, Respond, Recover
2. Incident Reporting
Tiered reporting system:
Major Incident (within 24 hours):
Initial notification to supervisor
High impact on operations
Significant Incident (within 72 hours):
Intermediate report with analysis
Root cause investigation
Final Report (within 1 month):
Complete post-incident analysis
Lessons learned
Preventive measures
3. Digital Operational Resilience Testing
Annual testing program must include:
Vulnerability assessments
Network security assessments
Physical security testing
Gap analyses
Software reviews
Open-source analysis
Penetration testing
Threat-Led Penetration Testing (TLPT)
TLPT - Advanced testing:
Required for largest financial entities
Simulates real-world attack scenarios
Red team exercises
Tests detection AND response capabilities
Must be done by certified testers
Minimum every 3 years
This is where your red team skills become valuable!
4. ICT Third-Party Risk Management
Critical focus of DORA: Banks don't run their own data centers anymore
Cloud providers (AWS, Azure, Google Cloud)
Payment processors
Core banking software vendors
Custody services
Requirements:
Pre-contractual risk assessment
Contractual arrangements with security clauses
Exit strategies - can switch providers if needed
Monitoring and testing of third parties
Register of third-party arrangements
Critical third-party providers: Designated by regulators, subject to:
Direct oversight
Regular audits
Strict security requirements
5. Information Sharing
Encourage sharing of cyber threat intelligence:
Between financial entities
With authorities
To improve collective defense
Protected information sharing:
Legal protections for sharing IOCs
No liability for sharing in good faith
DORA vs Other Regulations
Sector
All
Critical infrastructure
Financial only
Focus
Data protection
Infrastructure security
Operational resilience
Testing
Not specified
Risk-based
Mandatory TLPT
Third parties
Processors
Supply chain
Critical ICT providers
Penalties
Up to €20M/4%
Up to €10M/2%
Up to €10M/2%**
**DORA penalties can be higher for serious breaches
Practical Example: Bank Compliance
Bank: Mid-sized EU bank, 500k customers
Must comply with:
GDPR: Customer personal data
NIS2: As essential entity (banking sector)
DORA: As financial entity
PCI-DSS: For payment cards
National banking regulations
Overlapping requirements:
Incident Response:
GDPR: 72-hour breach notification (if personal data)
NIS2: 24-72 hour incident notification (if operational disruption)
DORA: Tiered reporting (24h/72h/30d) for ICT incidents
Solution: Single incident response process that meets all three
Third-Party Management:
NIS2: Supply chain security
DORA: ICT third-party risk management
GDPR: Processor agreements
Solution: Comprehensive vendor assessment program
Testing:
DORA: Annual testing, TLPT every 3 years
PCI-DSS: Annual pentest, quarterly scans
Best practice: Integrated testing schedule
ISO 27001 - Information Security Management
What is ISO 27001?
Full name: ISO/IEC 27001:2022 - Information security management systems (ISMS)
Type: International standard (not law)
Purpose:
Establish, implement, maintain information security management system
Certification available
Why Organizations Choose ISO 27001
Not legally required, but:
Often required by customers (B2B contracts)
Required for government tenders
Insurance discounts
Demonstrates security maturity
Provides structure for security program
The ISMS Approach
ISMS = Information Security Management System
Not just technical controls, but complete management system:
Policies and procedures
Risk management
Continuous improvement
Management responsibility
Based on PDCA cycle:
ISO 27001 Structure
Clauses 1-3: Introduction, scope, terms Clauses 4-10: Requirements (mandatory for certification) Annex A: 93 control objectives (select based on risk)
The 93 Controls (Annex A)
Organized into 4 themes:
Organizational Controls (37 controls)
Policies
Information security roles
Supplier relationships
Information security management
People Controls (8 controls)
Screening
Terms and conditions of employment
Information security awareness
Disciplinary process
Physical Controls (14 controls)
Physical security perimeter
Entry controls
Securing offices and facilities
Equipment security
Technological Controls (34 controls)
User access management
Access rights
Information backup
Logging and monitoring
Cryptography
Secure development
Vulnerability management
ISO 27001 Certification Process
Stage 1: Documentation Review Auditor reviews:
ISMS documentation
Risk assessment
Statement of Applicability (SoA)
Policies and procedures
Stage 2: Implementation Audit Auditor verifies:
Controls actually implemented
Controls operating effectively
Evidence collected
Certification:
Valid for 3 years
Annual surveillance audits
Recertification after 3 years
Cost:
Small organization: €10k-30k
Large organization: €50k-150k+
Annual maintenance: €5k-20k
ISO 27001 vs NIST CSF
Both are security frameworks, but different approaches:
Type
Certifiable standard
Voluntary framework
Origin
International (ISO)
US (NIST)
Approach
Process-focused (ISMS)
Outcome-focused (functions)
Certification
Yes, by accredited bodies
No
Cost
High (audit costs)
Free to use
Flexibility
Prescriptive process
Highly flexible
Best for
Demonstrating compliance
Building security program
Many organizations use both:
CSF for program structure
ISO 27001 for certification/proof
SOC 2 - Service Organization Control
What is SOC 2?
Origin: AICPA (American Institute of CPAs) Type: Audit framework for service providers Purpose: Demonstrate security to customers
Who Needs SOC 2?
Service providers, especially:
SaaS companies
Cloud providers
Data centers
Managed service providers
Why? Customers ask: "How do we know you're secure?"
Can't audit every vendor yourself
Independent third-party audit provides assurance
SOC 2 Trust Service Criteria
Based on 5 criteria:
1. Security (Required) Protection against unauthorized access
2. Availability (Optional) System available for operation and use
3. Processing Integrity (Optional) System processing is complete, valid, accurate
4. Confidentiality (Optional) Information designated confidential is protected
5. Privacy (Optional) Personal information collected, used, retained, disclosed properly
SOC 2 Types
Type I:
Point-in-time assessment
"Controls are designed appropriately"
Faster, cheaper
Less valuable
Type II:
Assessment over period (6-12 months)
"Controls operated effectively over time"
More rigorous
Preferred by customers
SOC 2 Report Structure
Section 1: Management's description of system Section 2: Auditor's opinion Section 3: Details of tests performed Section 4: Any exceptions/issues found
Important:
Reports are confidential
Shared under NDA with customers
Not public (unlike ISO 27001 certificate)
Other Important Standards and Regulations
HIPAA (Health Insurance Portability and Accountability Act)
Jurisdiction: United States Sector: Healthcare Protects: Protected Health Information (PHI)
Key requirements:
Administrative safeguards (policies, training)
Physical safeguards (facility access)
Technical safeguards (encryption, access control)
Breach notification (60 days)
Penalties:
Willful neglect: Up to $1.5M per violation
Criminal charges possible
Relevance for EU companies: If you provide services to US healthcare, HIPAA applies
CCPA/CPRA (California Privacy Laws)
Jurisdiction: California, US Type: State privacy law (like GDPR for California) Protects: California residents
Key rights:
Right to know what data collected
Right to deletion
Right to opt-out of sale
Right to non-discrimination
Relevance: If you have California customers, CCPA applies (extraterritorial like GDPR)
TISAX (Trusted Information Security Assessment Exchange)
Sector: Automotive industry Origin: Germany (VDA - German Association of Automotive Industry) Purpose: Information security assessment for suppliers
Why it exists:
Automotive supply chain is complex
Car manufacturers demand security from suppliers
Common assessment standard prevents duplicate audits
Based on: ISO 27001 + industry-specific requirements
Levels:
AL1: Low protection needs
AL2: Normal protection needs
AL3: High protection needs (prototypes, sensitive designs)
Compliance Mapping and Integration
The Challenge: Multiple Compliance Frameworks
Modern companies face multiple requirements:
Example: EU FinTech Company
GDPR (personal data)
PCI-DSS (payment cards)
NIS2 (financial critical infrastructure)
DORA (financial digital resilience)
ISO 27001 (customer requirement)
SOC 2 (US customers)
Nightmare scenario: Treat each separately
6 separate programs
Duplicate effort
Conflicting requirements
Unsustainable
The Solution: Unified Compliance Mapping
Map controls across frameworks:
Example: Multi-Factor Authentication
NIST CSF
PR.AC-07: Users are authenticated
PCI-DSS
Req 8.3: MFA for all remote access
ISO 27001
A.9.4.2: Access control to systems
GDPR
Art 32: Appropriate security measures
NIS2
Art 21: MFA implementation
DORA
Art 9: Strong authentication
Single implementation satisfies multiple requirements
Creating a Unified Control Framework
Practical Unified Compliance Example
Control: Encryption of Sensitive Data
Mapped to:
GDPR Article 32: Pseudonymization and encryption
PCI-DSS Req 3.4: Render PAN unreadable
NIS2 Article 21: Encryption and cryptography
DORA Article 9: Protection of data at rest and in transit
ISO 27001 A.8.24: Use of cryptography
SOC 2 CC6.7: Encryption in transit and at rest
Single policy: "All sensitive data must be encrypted using industry-standard algorithms (AES-256 for data at rest, TLS 1.2+ for data in transit)"
Single implementation:
Database encryption: Satisfies all frameworks
TLS on all web servers: Satisfies all frameworks
Single audit:
Verify encryption is enabled
Evidence used for all compliance reports
Benefits:
80% less duplicate work
Consistent security posture
Easier to maintain
Lower audit costs
Frameworks in Action
Building a Security Program: The Practical Approach
Let's walk through building a security program for a realistic company.
Company Profile:
Name: "SecurePay Solutions"
Type: Payment processing company
Size: 150 employees
Revenue: €50M
Customers: EU and US merchants
Location: Poland (EU)
Step 1: Identify Applicable Requirements
Mandatory:
GDPR: Processing customer personal data
PCI-DSS: Processing payment card data
NIS2: Payment services = essential sector
Polish national banking regulations
Customer-driven:
ISO 27001: Required by enterprise customers
SOC 2 Type II: Required by US customers
Framework for structure:
NIST CSF: Internally for organizing security program
Step 2: Governance Structure
Establish roles:
CISO responsibilities:
Overall security strategy
Risk management
Compliance oversight
Security budget
Report to Board quarterly
DPO (separate from CISO for independence):
GDPR compliance
Privacy impact assessments
Data subject requests
Regulatory liaison
Security Governance Committee:
Meets monthly
Reviews and approves policies
Prioritizes security projects
Risk acceptance decisions
Step 3: Risk Assessment
Asset identification:
Customer PII database
€20M
HIGH
HIGH
HIGH
Payment card data (encrypted)
€50M
CRITICAL
CRITICAL
CRITICAL
Transaction processing system
€5M/day
MEDIUM
CRITICAL
CRITICAL
Corporate email
€100k
MEDIUM
MEDIUM
MEDIUM
Website
€10k
LOW
MEDIUM
HIGH
Risk assessment results:
Critical Risks:
Payment system breach (PCI-DSS violation, business shutdown)
Ransomware on processing infrastructure (availability impact)
Insider threat with access to card data
High Risks: 4. DDoS attack on website 5. Third-party vendor breach (payment gateway provider) 6. Unpatched vulnerabilities in web applications
Medium Risks: 7. Phishing attacks on employees 8. Physical theft of laptops 9. Insufficient logging/monitoring
Step 4: Policy Hierarchy Development
Top-level policy: Information Security Policy
Approved by Board
Defines security strategy and principles
Updated annually
Supporting policies:
Acceptable Use Policy
Access Control Policy
Data Classification and Protection Policy
Incident Response Policy
Business Continuity and DR Policy
Third-Party Security Policy
Standards:
Password Standard (12 chars, complexity, MFA)
Encryption Standard (AES-256, TLS 1.2+)
Logging Standard (90-day retention, specific events)
Patch Management Standard (Critical patches: 72 hours)
Procedures:
How to configure MFA in Azure AD
How to classify data
How to report security incident
How to onboard new vendor
Guidelines:
Password manager recommendations
Secure coding practices
Phishing awareness tips
Step 5: Control Implementation (NIST CSF Mapping)
GOVERN:
✓ Security strategy approved by Board
✓ CISO role established with authority and budget
✓ Security Governance Committee operational
✓ Risk management framework implemented
IDENTIFY:
✓ Asset inventory maintained (CMDB)
✓ Data classification scheme implemented
✓ Risk assessment completed annually
✓ Vendor inventory and risk ratings
PROTECT:
✓ Network segmentation (CDE isolated)
✓ Firewall rules (DMZ, internal zones)
✓ MFA on all systems (Azure AD + Duo)
✓ Endpoint protection (CrowdStrike EDR)
✓ Encryption (Database TDE, disk encryption)
✓ Security awareness training (monthly)
✓ Vulnerability management (Tenable)
DETECT:
✓ SIEM deployed (Splunk)
✓ IDS/IPS (Suricata)
✓ File integrity monitoring (Tripwire)
✓ Security monitoring 24/7 (SOC team)
RESPOND:
✓ Incident response plan documented
✓ IR team identified and trained
✓ Tabletop exercises quarterly
✓ Communication templates prepared
RECOVER:
✓ Backup strategy (3-2-1 rule)
✓ DR site established
✓ DR testing twice yearly
✓ RTO: 4 hours for critical systems
✓ RPO: 1 hour
Step 6: Compliance Evidence Collection
GDPR:
Records of processing activities ✓
Privacy policy ✓
Data subject request procedures ✓
DPO appointment ✓
Breach notification procedure ✓
PCI-DSS:
SAQ D completed ✓
ASV scans quarterly (all pass) ✓
Internal pentest annually ✓
Compensating controls documented ✓
NIS2:
Risk management framework ✓
Incident reporting procedure (24h) ✓
Supply chain security assessment ✓
Management oversight documented ✓
ISO 27001:
ISMS documentation ✓
Risk treatment plan ✓
Statement of Applicability (SoA) ✓
Internal audits completed ✓
External certification audit: Passed ✓
Step 7: Continuous Monitoring and Improvement
Monthly metrics:
Critical vulnerabilities: 0 (target)
Mean time to patch critical: 48 hours (target: 72h)
Security incidents: 3 (low severity)
MFA adoption: 100%
Training completion: 97%
Quarterly review:
Security Governance Committee reviews metrics
Risk register updated
Policy effectiveness reviewed
Budget adjustments
Annual:
Full risk assessment
Policy review and updates
Penetration test
DR test
Management review of ISMS
The Integrated Compliance Dashboard
Single view of compliance status:
GDPR
✓ Compliant
Jun 2024
Jun 2025
0
PCI-DSS
✓ Compliant
Mar 2024
Mar 2025
2 (low)
NIS2
✓ Compliant
Oct 2024
Oct 2025
0
ISO 27001
✓ Certified
Jan 2024
Jan 2025
3 (obs)
SOC 2 Type II
✓ Clean
Apr 2024
Apr 2025
0
Benefits of unified approach:
One security program satisfies all
Single set of evidence
Consistent reporting
Lower audit costs
Better security outcomes
Bringing It All Together: The Big Picture
The GRC Lifecycle in Practice
Why This Matters for Your Career
As cybersecurity professionals, you might think GRC is "boring" compared to pentesting or incident response. This is wrong thinking.
Reality:
Pentesting finds vulnerabilities
GRC ensures they get fixed
Blue team detects incidents
GRC ensures proper response and prevention
You discover a critical issue
GRC provides authority and budget to address it
Career impact:
Entry-level: Technical security roles (pentester, SOC analyst)
Mid-level: Senior technical + some GRC (risk assessments, compliance)
Senior-level: Security architect, security manager - heavy GRC focus
Executive-level: CISO - GRC is 80% of the job
Why? Business leaders understand risk and compliance. They don't always understand technical details.
The Complete Security Professional
Technical skills (what you've learned in red team/blue team):
Exploitation techniques
Malware analysis
Network security
Incident response
DFIR
GRC skills (what this module teaches):
Risk assessment and quantification
Policy development
Compliance management
Security governance
Business communication
Combined = powerful professional:
You understand what's technically possible (red team)
You can detect and respond (blue team)
You can quantify risk for business (GRC)
You can justify security spending (GRC)
You can ensure compliance (GRC)
Common Career Paths
Path 1: Technical → GRC Specialist
Start: SOC Analyst / Pentester
Move: Security Engineer with compliance focus
Move: Compliance Manager / Risk Manager
Senior: Chief Risk Officer / Chief Compliance Officer
Path 2: Technical → Leadership
Start: SOC Analyst / Pentester
Move: Senior Security Engineer
Move: Security Architect (technical + GRC)
Move: Security Manager (people + GRC)
Senior: CISO
Path 3: Specialized Consultant
Start: Technical security role
Develop: GRC expertise (certifications)
Move: Security consultant
Specialize: GDPR consultant, PCI-DSS assessor, ISO 27001 auditor
Senior: Independent consultant / Partner at consulting firm
The Most Important Takeaway
GRC is not separate from security - it IS security at the organizational level.
Every technical control you implement should trace back to:
A business need (governance)
A risk that was assessed (risk management)
A requirement that must be met (compliance)
Without GRC:
Security is random and reactive
Budget is impossible to justify
Controls are inconsistent
Incidents are handled poorly
The organization is exposed to legal and financial risk
With GRC:
Security is strategic and proactive
Investments are justified by risk and ROI
Controls are consistent and effective
Incidents are handled systematically
The organization is protected legally and financially
This is why GRC matters.
Last updated