governance

# Governance Skill

Security governance programme design covering the full lifecycle from policy
framework through board reporting and third-party risk. Start with policy
framework to establish the hierarchy, then assess maturity, design metrics,
and build TPRM capability.


## policy-framework

# Policy Framework

## Purpose
Establish a coherent, maintained security policy hierarchy aligned to ISO 27001 and NIST CSF.

---

## 1. Policy Hierarchy

| Level | Document Type | Audience | Approval | Review |
|-------|--------------|----------|---------|--------|
| 1 | Policy | All staff, Board | Board/CEO | Annual |
| 2 | Standard | Technical/Operations | CISO | Annual |
| 3 | Procedure | Operations team | IT Manager | Biannual |
| 4 | Guideline | Practitioners | Team Lead | As needed |

- **Policy**: High-level intent and commitment (e.g., "The organisation will protect information assets")
- **Standard**: Mandatory measurable requirements (e.g., "Passwords must be minimum 12 characters")
- **Procedure**: Step-by-step instructions (e.g., "How to provision a new user account")
- **Guideline**: Recommended best practices, not mandatory

---

## 2. Core Security Policies Required

### Mandatory Policy Suite (ISO 27001 / NIST CSF)
```
1. Information Security Policy (master policy)
2. Acceptable Use Policy
3. Access Control Policy
4. Cryptography Policy
5. Information Classification and Handling Policy
6. Incident Management Policy
7. Business Continuity and Disaster Recovery Policy
8. Change Management Policy
9. Vendor and Third-Party Security Policy
10. Physical Security Policy
11. Remote Working Policy
12. Secure Development Policy
13. Data Retention and Disposal Policy
14. Vulnerability Management Policy
```

---

## 3. Policy Lifecycle Management

### Annual Review Process
```
Month 1:  CISO initiates policy review cycle; notifies all policy owners
Month 2:  Policy owners review and update their policies
Month 3:  CISO reviews changes; legal/HR/IT review cross-functional impacts
Month 4:  Updated policies presented to Security Steering Committee for approval
Month 5:  Board approval for master policy and any significant changes
Month 6:  Published to intranet/GRC platform; staff notified
Ongoing:  Staff acknowledgement tracked; non-acknowledgement escalated
```

### Version Control Fields
```
Policy Name, Policy ID, Version, Status (Draft/Review/Approved/Retired),
Owner, Approver, Effective Date, Review Date, Change History,
Distribution (All Staff / IT / Executives)
```

---

## 4. Exception Management Process

```
POLICY EXCEPTION REQUEST
=========================
Exception ID:      EXC-<YYYY>-<nnnn>
Requested By:      <Name, Role, Business Unit>
Date:              <YYYY-MM-DD>
Policy Violated:   <Policy Name, Section>
Description:       <What cannot be complied with and why>
Business Justification: <Business reason>
Risk Assessment:   <Likelihood + Impact + Risk Level>
Compensating Controls: <What mitigates the risk>
Duration:          <time-limited: max 12 months>
Risk Owner:        <Business VP/Director who accepts the risk>
CISO Approval:     <Signature + Date>
Board Notification: <Required if risk = High/Critical>
Review Date:       <Date to reassess>
```

---

## 5. Staff Acknowledgement Tracking

```
Requirements:
- New staff: acknowledge all policies within first 5 working days
- Annual renewal: all staff acknowledge by specific date
- Policy update: acknowledgement required within 10 working days

Tracking metrics:
- Acknowledgement rate by department
- Overdue acknowledgements (escalate > 30 days overdue to manager)
- Exception rate (track declining acknowledgements as training indicator)

Tools: GRC platform, ServiceNow, or SharePoint acknowledgement workflow
```

---

## 6. Gap Analysis Against ISO 27001 Annex A

```
Map each policy to ISO 27001:2022 Annex A controls:
  Information Security Policy → A.5.1 Policies for information security
  Access Control Policy       → A.8.2, A.8.3, A.8.4, A.8.5
  Cryptography Policy         → A.8.24 Use of cryptography
  Incident Management Policy  → A.5.24, A.5.25, A.5.26
  Vendor Policy               → A.5.19, A.5.20, A.5.21, A.5.22

Document:
  [ ] Policy exists: Y/N
  [ ] Covers all relevant controls: Y/Partial/N
  [ ] Approved and current: Y/N (within 12 months)
  [ ] Staff aware and acknowledged: Y/N
  [ ] Gap description (if partial/no)
```



## program-maturity

# Program Maturity

## Purpose
Assess current security programme maturity against recognised frameworks, benchmark against industry peers, and define a roadmap to target maturity.

---

## 1. NIST CSF 2.0 Tier Assessment

### Tier Definitions
| Tier | Name | Description |
|------|------|-------------|
| 1 | Partial | Ad hoc, reactive; no formal programme; risk not consistently managed |
| 2 | Risk Informed | Risk practices exist but not organisation-wide; awareness but not policy-driven |
| 3 | Repeatable | Formally approved policy; organisational approach; regularly updated |
| 4 | Adaptive | Risk management is part of culture; adapts to threats in near-real-time |

### Assessment Per CSF Function
```
For each function (Govern, Identify, Protect, Detect, Respond, Recover):

Assessment questions:
  1. Are practices formalised in policy? [Y/N]
  2. Are practices applied consistently across the organisation? [Y/N]
  3. Are practices reviewed and updated regularly? [Y/N]
  4. Is there executive/board awareness and support? [Y/N]
  5. Does the organisation adapt based on threat intelligence? [Y/N]

Scoring:
  0-1 Y answers = Tier 1
  2-3 Y answers = Tier 2
  4 Y answers   = Tier 3
  5 Y answers   = Tier 4

Current tier per function:
  Govern:   <1/2/3/4>
  Identify: <1/2/3/4>
  Protect:  <1/2/3/4>
  Detect:   <1/2/3/4>
  Respond:  <1/2/3/4>
  Recover:  <1/2/3/4>
  
  Overall: <average or weighted score>
  Target:  <desired tier within 12/24 months>
```

---

## 2. CMMC Level Assessment (US DoD Contractors)

| Level | Requirements | Target Org |
|-------|-------------|-----------|
| Level 1 | 17 practices from FAR 52.204-21 | FCI-only contractors |
| Level 2 | 110 practices from NIST SP 800-171 | CUI contractors |
| Level 3 | 110 NIST + 24 additional NIST 800-172 practices | High-priority CUI |

Level 2 key practice domains:
- Access Control (AC): 22 practices
- Audit and Accountability (AU): 9 practices
- Configuration Management (CM): 9 practices
- Identification and Authentication (IA): 11 practices
- Incident Response (IR): 3 practices
- Maintenance (MA): 6 practices
- Media Protection (MP): 9 practices
- Personnel Security (PS): 2 practices
- Physical Protection (PE): 6 practices
- Risk Assessment (RA): 5 practices
- Security Assessment (CA): 4 practices
- System and Communications Protection (SC): 16 practices
- System and Information Integrity (SI): 7 practices

---

## 3. Security Steering Committee Charter

```
SECURITY STEERING COMMITTEE CHARTER
=====================================
Purpose: Provide executive oversight, direction, and governance for the
         information security programme.

Membership:
  Chair:          CISO
  Members:        CTO, CRO, General Counsel, CPO, Head of HR,
                  Business Unit Leads (rotating), Internal Audit

Meeting Cadence: Quarterly (monthly in high-risk periods)

Standing Agenda:
  1. Approval of action items from last meeting
  2. Security programme dashboard review (KPIs, KRIs)
  3. Risk register review (material changes)
  4. Policy exception approvals
  5. Incident and near-miss review
  6. Upcoming compliance obligations
  7. Investment priorities

Decision Rights:
  Approve/reject risk acceptance > Medium threshold
  Approve security programme investments > $<threshold>
  Approve policy exceptions for High/Critical risks
  Escalate Critical risks to Board

Quorum: CISO + any 3 members
```

---

## 4. Maturity Roadmap Template

```
SECURITY PROGRAMME MATURITY ROADMAP
=====================================
Assessment Date:    <YYYY-MM-DD>
Current Maturity:   NIST CSF Tier <n> overall
Target Maturity:    NIST CSF Tier <n> by <date>

12-Month Initiatives (Tier 1 to Tier 2):
  Q1: Formal risk assessment process; document asset inventory
  Q2: Core security policies approved; training programme launched
  Q3: Vulnerability management process; patch SLAs defined
  Q4: Security steering committee established; metrics dashboard live

24-Month Initiatives (Tier 2 to Tier 3):
  Q1-Q2: Threat intelligence integration; SIEM deployment
  Q3-Q4: Third-party risk programme; incident response exercises

Benchmark comparison:
  Industry sector average (NIST CSF tier): <n>
  Our current:                              Tier <n>
  Target:                                   Tier <n>
  
  (Source: CIS/SANS annual security survey for sector)
```



## metrics-and-reporting

# Metrics and Reporting

## Purpose
Design meaningful security KPIs, KRIs, and reporting for different audiences from board-level to operational teams.

---

## 1. KPI Examples (Key Performance Indicators)

| KPI | Description | Target | Frequency |
|-----|-------------|--------|-----------|
| MFA adoption rate | % accounts with MFA enabled | > 98% | Monthly |
| Patch compliance (critical) | % critical CVEs patched within SLA | > 95% | Monthly |
| Mean time to patch (critical) | Avg days to patch critical CVEs | < 15 days | Monthly |
| Security training completion | % staff completed annual training | > 95% | Annual/Quarterly |
| Phishing simulation click rate | % staff clicking simulated phishing | < 5% | Quarterly |
| Vulnerability scan coverage | % in-scope assets scanned monthly | > 99% | Monthly |
| Incident response SLA | % P1 incidents responded to in < 1h | > 95% | Monthly |
| Access review completion | % overdue access reviews | < 2% | Quarterly |
| Policy acknowledgement rate | % staff who acknowledged all policies | > 95% | Annual |
| Pen test finding remediation | % critical pen test findings closed | > 90% in 30d | Post-test |

---

## 2. KRI Examples (Key Risk Indicators)

| KRI | Threshold (Amber) | Threshold (Red) | Frequency |
|-----|-------------------|-----------------|-----------|
| Overdue critical vulnerabilities | > 5 | > 20 | Weekly |
| Failed pen test critical findings | Any open > 30 days | Any open > 60 days | Monthly |
| Third-party security incidents | 1 per quarter | > 2 per quarter | Quarterly |
| Data breach near-misses | 1 per month | > 3 per month | Monthly |
| Unpatched admin accounts | > 2 | > 5 | Weekly |
| SoD violations | > 5 | > 20 | Monthly |
| Mean time to detect (MTTD) | > 48 hours | > 1 week | Monthly |
| Privileged accounts without MFA | Any | Any | Immediate |
| Days since last DR test | > 365 | > 730 | Ongoing |
| Overdue vendor assessments | > 5% | > 15% | Quarterly |

---

## 3. Board-Level Reporting Format

### Quarterly Board Report Structure
```
INFORMATION SECURITY REPORT — BOARD Q<n> <YEAR>
=================================================
1. EXECUTIVE SUMMARY (1/2 page)
   - Key security posture sentence
   - Any material incidents during period
   - Programme highlights
   - 1-2 key risks requiring board awareness

2. SECURITY POSTURE SCORECARD
   [Risk Heat Map: 5x5 grid showing top risks by likelihood x impact]
   [Trend vs prior quarter: arrows up/down/stable per domain]
   
   Domain          Status    Trend    Score
   ─────────────────────────────────────────
   Identity/Access GREEN     →        8/10
   Endpoint        AMBER     ↑        6/10
   Cloud           GREEN     →        7/10
   Third Party     AMBER     ↓        5/10
   Resilience      GREEN     →        8/10

3. KEY METRICS (3-5 metrics maximum)
   - MFA adoption: 97% (target: 98%)
   - Critical patch compliance: 92% (target: 95%) [AMBER]
   - Security training: 94% (target: 95%)

4. PROGRAMME PROGRESS (vs plan)
   - Initiatives on track vs off track
   - Budget spend vs plan
   - Key milestones achieved

5. TOP RISKS
   [Table: risk, current rating, treatment status, expected resolution]

6. KEY INCIDENTS
   [Brief summary of any material incidents; no sensitive detail]

7. REGULATORY UPDATE
   [Any upcoming compliance obligations or regulatory changes]
```

---

## 4. Security Scorecard Design

### Weighted Domain Scorecard
```
Domain               Weight  Score  Weighted  Status
─────────────────────────────────────────────────────
Identity & Access    25%     7.5    1.875     AMBER
Endpoint Security    15%     8.0    1.200     GREEN
Network Security     15%     7.0    1.050     AMBER
Application Security 15%     6.0    0.900     AMBER
Cloud Security       10%     7.5    0.750     GREEN
Data Protection      10%     8.0    0.800     GREEN
Third-Party Risk     5%      5.0    0.250     AMBER
Resilience          5%      8.5    0.425     GREEN
─────────────────────────────────────────────────────
TOTAL               100%           7.25      AMBER

Score interpretation:
  GREEN  = 8.0 - 10.0
  AMBER  = 6.0 - 7.9
  RED    = 0.0 - 5.9
```

---

## 5. Reporting Frequency by Audience

| Audience | Frequency | Format | Content Focus |
|----------|-----------|--------|--------------|
| Board | Quarterly | 2-page report + heat map | Risk posture, top risks, programme progress |
| CISO/Executives | Monthly | Dashboard + narrative | KPIs, KRIs, incidents, emerging threats |
| Security Steering | Monthly | Full dashboard + agenda | Programme performance, approvals needed |
| SOC/Operations | Weekly | Operational dashboard | Open incidents, overdue patches, alerts |
| Threat Intel | Daily | Briefing + IOC updates | New threats, active campaigns |



## third-party-governance

# Third-Party Governance

## Purpose
Design and operate a risk-based Third-Party Risk Management (TPRM) programme covering the full vendor lifecycle.

---

## 1. TPRM Lifecycle Phases

| Phase | Description | Key Activities |
|-------|-------------|---------------|
| Pre-engagement | Due diligence before contracting | Initial risk assessment, security questionnaire |
| Contracting | Security requirements in contract | Data handling clauses, breach notification, right to audit |
| Onboarding | Technical and process integration | Access provisioning, integration security review |
| Ongoing monitoring | Continuous and periodic oversight | Annual reassessment, news monitoring, performance review |
| Off-boarding | Secure termination | Access revocation, data return/destruction, final review |

---

## 2. Vendor Risk Tiering

### Tiering Criteria
| Factor | Weight | Assessment |
|--------|--------|-----------|
| Data access (type and volume of data) | 40% | None / Low / Medium / High sensitivity |
| Business criticality | 35% | Non-critical / Operational / Critical / Mission-critical |
| Integration depth | 25% | None / API / Network integration / Direct system access |

### Risk Tier Definitions
| Tier | Score | Description | Examples |
|------|-------|-------------|---------|
| Critical | 8-10 | Processes restricted data; mission-critical service | Cloud CSP, payment processor, HR SaaS |
| High | 6-7 | Processes confidential data; important operational service | Pen test firm, audit firm, SIEM vendor |
| Medium | 4-5 | Limited data access; operational but not critical | Software tool vendors, training platforms |
| Low | 1-3 | No sensitive data; non-critical | Office supplies, catering, facilities |

---

## 3. Tiered Assessment Approach

### Critical Tier
```
Pre-engagement:
  - Full security questionnaire (CAIQ, SIG, or custom)
  - Evidence review: SOC 2 Type II, ISO 27001 certificate, pen test summary
  - On-site assessment or virtual equivalent
  - Legal/Procurement/Security sign-off required

Ongoing:
  - Annual full reassessment
  - Continuous monitoring (SecurityScorecard, BitSight, RiskRecon)
  - Real-time incident notification SLA: 2 hours
  - Quarterly business reviews (include security agenda item)
```

### High Tier
```
Pre-engagement:
  - Security questionnaire
  - Evidence review: SOC 2 or ISO cert
  - Security approval required

Ongoing:
  - Annual reassessment
  - Review of material changes (M&A, major breaches)
  - Incident notification SLA: 24 hours
```

### Medium Tier
```
Pre-engagement:
  - Abbreviated questionnaire (10-15 questions)
  - Review self-assessment

Ongoing:
  - Biennial reassessment
  - Incident notification SLA: 72 hours
```

### Low Tier
```
Pre-engagement:
  - Standard contractual requirements only
  - No assessment required

Ongoing:
  - No active monitoring
  - Contract renewal review
```

---

## 4. Contract Security Requirements

### Mandatory Clauses (all tiers)
```
Data Handling and Processing:
  - Definition of permitted uses of company data
  - Prohibition on sub-processing without approval
  - Data residency requirements (geography)
  - Data deletion on termination (specify format, timeline, certification)

Breach Notification:
  Critical/High: 2 hours for suspected breach, 24 hours for confirmed
  Medium:        24 hours for confirmed breach
  All:           Assist with investigation; provide logs on request

Security Standards:
  Requirement to maintain ISO 27001 or equivalent (or SOC 2)
  Requirement to conduct annual penetration testing
  Patch critical vulnerabilities within defined SLA

Right to Audit:
  Right to conduct or commission security assessment with reasonable notice
  Right to review evidence of compliance with security requirements
  Subprocessor controls: vendor must flow down requirements to subs

Incident Cooperation:
  Provide reasonable assistance to forensic investigations
  Preserve logs for defined period
  Named security contact with 24/7 availability for Critical vendors
```

---

## 5. Continuous Monitoring Programme

### Technology-Based Monitoring (Critical/High vendors)
- **SecurityScorecard**: External attack surface; domain reputation; certificate issues
- **BitSight**: Similar to SecurityScorecard; industry benchmarking
- **RiskRecon**: Detailed findings on exposed vulnerabilities and misconfigurations

Triggers for immediate reassessment:
- Public breach or data exposure incident involving vendor
- Material change: M&A, major executive change, regulatory action
- SecurityScorecard/BitSight score drops by > 10 points
- Vendor loses key security certification (SOC 2 qualified opinion)

---

## 6. TPRM Programme Metrics

| Metric | Target |
|--------|--------|
| Vendor inventory coverage (all known vendors assessed) | 100% |
| Critical/High vendors with current assessment | > 95% |
| Overdue Critical vendor reassessments | 0 |
| Vendors without required security clause in contract | < 5% |
| Time to complete new vendor assessment (Critical) | < 15 days |
| Incident notification SLA compliance by vendors | 100% |
| SecurityScorecard average for Critical vendors | > 70/100 |