Risk Management Policy

1. Purpose

Defines the framework for identifying, assessing, treating, and monitoring information security risks at Meridian Seven. Satisfies Trust Services Criteria CC3.1–CC3.4 (Risk Assessment) and CC9.1–CC9.2 (Risk Mitigation).

2. Scope

All systems, applications, and infrastructure in the Information Security Policy
All business processes that create, store, process, or transmit customer or company data
All employees, contractors, and third-party service providers
All environments: production, staging, development, and disaster recovery

3. Risk Governance

3.1 Roles and Responsibilities

Role	Responsibility
CTO	Approves risk appetite and tolerance; accepts/rejects risks exceeding CISO authority; quarterly risk review
CISO	Owns risk management program; conducts assessments; maintains risk register; reports posture to leadership
Engineering Lead	Identifies and reports technical risks; implements assigned treatment actions; validates remediation
Data Owners	Identify data-related risks; participate in assessments for owned systems
All Personnel	Report potential risks, threats, and vulnerabilities to the CISO

3.2 Risk Appetite

Meridian Seven has a low risk appetite for threats to customer data confidentiality, system integrity, and service availability:

No risk of unencrypted customer data at rest or in transit
No risk of production access without MFA
Low risk for service unavailability (target: 99.9% uptime)
Moderate risk for non-production disruptions that do not affect customer data

Risk acceptance exceeding these thresholds requires written CTO approval.

4. Risk Assessment Process

4.1 Assessment Frequency

Type	Frequency	Trigger
Comprehensive	Annually	Q1 calendar-driven
Targeted	As needed	New system, significant architecture change, incident, or regulatory change
Continuous monitoring	Ongoing	Automated via compliance verification framework

4.2 Risk Identification (CC3.1)

Threat categories:

External — Unauthorized access, malware, phishing, supply chain compromise, DDoS
Internal — Insider misuse, accidental data exposure, misconfiguration, credential compromise
Environmental — Cloud provider outages, third-party failures, natural disasters
Compliance — Regulatory changes, contractual changes, audit findings
Operational — Key person dependency, process failures, inadequate change management
Fraud (CC3.3) — Management override of controls, unauthorized data exfiltration, misrepresentation of compliance posture

Fraud risk is explicitly assessed during each risk assessment cycle. Fraud risks are documented in the risk register (automation/config/risk-register.yaml) with specific mitigation actions including segregation of duties, audit logging, automated compliance verification, and DLP controls.

Sources: automated compliance results (automation/reports/status.json), GCP Cloud Monitoring alert data, CrowdStrike alerts, Dependabot/secret scanning alerts, vendor SOC reports, CISA advisories, OWASP Top 10, internal post-mortems.

4.3 Risk Analysis (CC3.2, CC3.3)

Likelihood:

Score	Rating	Definition
1	Rare	Less than once per year
2	Unlikely	Once per year; occurred in similar organizations
3	Possible	Once per quarter; known industry trend
4	Likely	Once per month; active threat with demonstrated capability
5	Almost Certain	Weekly or more; ongoing active exploitation

Impact:

Score	Rating	Definition
1	Negligible	No customer impact; internal inconvenience only
2	Minor	Limited disruption; no data exposure; resolved within SLA
3	Moderate	Customer-facing service degradation; potential compliance finding
4	Major	Data breach affecting limited customers; regulatory notification required
5	Critical	Large-scale breach; extended outage; material business impact; legal action

Risk Rating = Likelihood × Impact:

Rating	Score	Treatment Required
Critical	16–25	Immediate remediation; CTO approval to accept
High	10–15	Remediation within 30 days; CTO approval required to accept
Medium	5–9	Remediation within 90 days; tracked in risk register
Low	1–4	Accept or remediate opportunistically; reviewed annually

4.4 Risk Treatment (CC3.4)

Strategy	Description	When to Use
Mitigate	Implement controls to reduce likelihood or impact	Risk is within organizational capability to address
Transfer	Shift risk to a third party (insurance, vendor SLA)	Risk is better managed by a specialized party
Accept	Acknowledge and monitor without further action	Residual risk is within appetite after analysis
Avoid	Eliminate the activity or system creating the risk	Risk exceeds appetite and cannot be adequately mitigated

Risk acceptance requires documented justification, CISO approval (Medium and below) or CTO approval (High and Critical), and a defined review date (max 12 months). Accepted risks are recorded in the risk register (automation/config/risk-register.yaml).

5. Risk Register

5.1 Location and Format

Maintained at automation/config/risk-register.yaml. Each entry contains:

Field	Description
`id`	Unique identifier (RISK-001, RISK-002, …)
`title`	Brief description
`category`	external / internal / environmental / compliance / operational
`cc_controls`	Applicable TSC codes
`likelihood`	Score 1–5
`impact`	Score 1–5
`rating`	Critical / High / Medium / Low
`treatment`	Mitigate / Transfer / Accept / Avoid
`owner`	Person responsible for treatment
`mitigation_actions`	Specific reduction actions
`status`	Open / In Progress / Mitigated / Accepted
`target_date`	Treatment completion date
`review_date`	Next review date
`notes`	Additional context or justification

5.2 Maintenance

CISO updates register after each assessment
New risks added within 5 business days of identification
Closed or mitigated risks retained for audit trail
Full register reviewed at each quarterly risk review

6. Risk Monitoring (CC9.1, CC9.2)

6.1 Continuous Monitoring

System	Risk Signal	Frequency
Compliance verification framework	Control failures (FAIL/ERROR/WARN)	Nightly
CrowdStrike Falcon	Endpoint threats and detections	Real-time
GCP Cloud Monitoring	Service availability and uptime checks	Real-time
GitHub Dependabot	Dependency vulnerabilities	On push
GitHub Secret Scanning	Exposed credentials in code	On push
Claude Security Review	AI-powered security review	On PR
Cloudflare	WAF events and rate limiting	Real-time

6.2 Risk Reporting

Report	Audience	Frequency	Content
Weekly Security Review	CISO, Engineering	Weekly	New risks, control failures, incident summary
Risk Posture Summary	CTO	Quarterly	Register status, trend analysis, treatment progress
Annual Risk Assessment Report	CTO, Board	Annually	Comprehensive risk landscape, year-over-year comparison

6.3 Risk Escalation

Escalate when:

A new Critical-rated risk is identified
A treatment action misses its target date by more than 30 days
An accepted risk’s conditions change materially
Multiple related Medium risks collectively represent High or Critical exposure

Escalation path: Engineering Lead → CISO → CTO.

7. Integration with Other Processes

Process	Integration Point
Incident Response	Post-incident risk assessment; register updates after incidents
Change Management	Risk evaluation for significant changes; new system risk assessment
Vendor Management	Third-party risk assessment during onboarding and annual review
Access Control	Risk-based access decisions; privileged access risk tracking
Business Continuity	Recovery priority based on risk rating; DR testing informed by risk assessment

8. Policy Review

Annual review or upon significant changes to business, technology, or threat environment. CISO initiates; CTO approves all substantive changes.

Information Security Policy
Incident Response Plan
Change Management Policy
Vendor Management Policy
Backup and Recovery Policy
Access Control Policy
Data Classification Policy

Meridian Seven — Confidential