Beginner

# Nexatech Information Classification Scheme v1.0
 
## Classification Levels
 
| Label        | Definition                                  | Examples                          | Default Handling                                               |
| ------------ | ------------------------------------------- | --------------------------------- | -------------------------------------------------------------- |
| Public       | Approved for unrestricted external release  | Marketing copy, job postings      | No special controls                                            |
| Internal     | For employees only; limited business impact | Meeting notes, project wikis      | Do not share externally without approval                       |
| Confidential | Significant harm if disclosed outside org   | Customer PII, source code, deals  | Encrypt at rest and in transit; NDA required for third parties |
| Restricted   | Severe or irreversible harm if disclosed    | PCI card data, M&A plans, HR docs | Encrypt + access log + MFA + need-to-know                      |
 
## Classification Rules
 
# => Every new data asset MUST be assigned a label at creation time
 
# => Default label when uncertain: Confidential (err on the side of caution)
 
# => Labels travel with the data (email subject lines, file names, headers)
 
# => Downgrading a label requires manager + security team approval
 
# => Annual review of all Restricted assets is mandatory

# AcmeSoft Acceptable Use Policy
 
# Version: 1.2 | Owner: CISO | Review: Annual | Classification: Internal
 
## 1. Purpose
 
# => State WHY the policy exists — auditors check this section first
 
This policy defines acceptable use of AcmeSoft information systems to
protect company assets and ensure regulatory compliance.
 
## 2. Scope
 
# => Who and what this policy covers — must be unambiguous
 
Applies to: all employees, contractors, and third-party vendors
Covers: all AcmeSoft systems, networks, devices, and data (owned or BYOD)
 
## 3. Acceptable Use
 
# => List permitted behaviors explicitly — reduces ambiguity
 
- Use company systems primarily for business purposes
- Personal use is permitted in moderation and must not interfere with work
- Access only systems and data required for your role
 
## 4. Prohibited Use
 
# => Explicit prohibitions reduce "I didn't know" defenses
 
- Sharing credentials with colleagues or third parties
 
# => This is the #1 vector for insider-threat incidents
 
- Installing unauthorized software on company devices
- Accessing, storing, or transmitting illegal content
- Using company resources for personal financial gain
 
# => Covers crypto mining, side-business hosting, etc.
 
- Circumventing security controls (VPN, MFA, DLP tools)
 
## 5. Monitoring
 
# => Legal requirement to disclose monitoring in most jurisdictions
 
AcmeSoft reserves the right to monitor systems for security and
compliance purposes. Users have no expectation of privacy on
company-owned systems.
 
## 6. Violations
 
# => Clear consequence ladder reduces inconsistent enforcement
 
Violations may result in: warning → suspension → termination → legal action
Severity determined by: data classification of affected asset + intent
 
## 7. Acknowledgement
 
# => Signed acknowledgement is required for enforcement and audit evidence
 
I have read and understood this policy: **\*\*\*\***\_\_\_\_**\*\*\*\*** Date: **\_\_\_\_**

# Nexatech Information Security Policy
 
# Version: 2.0 | Approved by: CEO | Owner: CISO | Review cycle: Annual
 
## 1. Management Statement of Intent
 
# => Senior leadership signature is mandatory — this legitimizes the program
 
Nexatech management is committed to protecting the confidentiality,
integrity, and availability of all information assets. Security is a
business priority, not solely a technical function.
 
## 2. Scope
 
# => ISO 27001 Clause 4.3 requires documented scope
 
All Nexatech information assets, personnel, processes, and technology
systems used to deliver payment processing services, including cloud
infrastructure and third-party integrations.
 
## 3. Objectives
 
# => Measurable objectives — link to annual security metrics (see Example 24)
 
- Maintain zero critical unpatched vulnerabilities > 30 days
- Achieve < 2-hour mean time to detect (MTTD) for high-severity incidents
- 100% employee security awareness training completion annually
 
## 4. Roles and Responsibilities
 
# => Clear ownership prevents "not my job" gaps
 
| Role          | Responsibility                              |
| ------------- | ------------------------------------------- |
| CEO           | Ultimate accountability; approves IS Policy |
| CISO          | Program ownership; reports to CEO quarterly |
| IT Manager    | Technical control implementation            |
| All Employees | Comply with policies; report incidents      |
| Data Owners   | Classify data; approve access requests      |
 
## 5. Supporting Policies
 
# => The ISP is the parent; these are children — auditors check alignment
 
- Acceptable Use Policy
- Access Control Policy
- Incident Response Policy
- Data Classification Policy
- Vendor Risk Management Policy
 
# => Each child policy must reference this document as its authority
 
## 6. Compliance and Enforcement
 
# => Explicit statement of consequences required for ISO 27001 A.5.1
 
Non-compliance with this policy may result in disciplinary action up to
and including termination and referral to law enforcement.
 
## 7. Review and Approval
 
# => Document must be reviewed and re-approved annually
 
Last approved: 2026-05-21 | Next review: 2027-05-21
Approved by: [CEO signature]

# AcmeSoft Risk Register — Initial Population
# Owner: CISO | Date: 2026-05-21 | Classification: Confidential
# Columns: ID | Asset | Threat | Vulnerability | Likelihood | Impact | Inherent Risk
 
risks:
  - id: RISK-001
    asset: "Customer PII database (PostgreSQL, AWS RDS)"
    # => Asset: what we are protecting
    threat: "External attacker exfiltrates customer records"
    # => Threat: the actor or event that could cause harm
    vulnerability: "Database credentials stored in plaintext in app config files"
    # => Vulnerability: the weakness the threat exploits
    likelihood: 4 # => 1=Rare, 2=Unlikely, 3=Possible, 4=Likely, 5=Almost certain
    impact: 5 # => 1=Negligible, 2=Minor, 3=Moderate, 4=Major, 5=Catastrophic
    inherent_risk: 20 # => likelihood × impact = raw score before controls
    owner: "Engineering Lead"
 
  - id: RISK-002
    asset: "Employee laptops (MacBook fleet, 200 devices)"
    threat: "Theft or loss of unencrypted device"
    vulnerability: "Full-disk encryption not enforced via MDM policy"
    likelihood: 3
    impact: 3
    inherent_risk: 9
    owner: "IT Manager"
 
  - id: RISK-003
    asset: "AWS production account"
    threat: "Insider misuse — engineer deletes production resources"
    vulnerability: "No separation of duties; all engineers have admin IAM access"
    likelihood: 2
    impact: 5
    inherent_risk: 10
    owner: "CISO"
 
  - id: RISK-004
    asset: "Third-party payroll SaaS (PayrollCo)"
    threat: "Supply chain breach — vendor compromised, employee PII leaked"
    vulnerability: "No vendor security assessment performed; no contractual security requirements"
    likelihood: 2
    impact: 4
    inherent_risk: 8
    owner: "HR Director"
 
  - id: RISK-005
    asset: "Customer-facing login API"
    threat: "Credential stuffing attack causes account takeovers"
    vulnerability: "No rate limiting or MFA enforcement on login endpoint"
    likelihood: 4
    impact: 4
    inherent_risk: 16
    owner: "Engineering Lead"

# AcmeSoft Risk Scoring Matrix
 
# Risk Score = Likelihood (1–5) × Impact (1–5) | Range: 1–25
 
## The Matrix
 
| Likelihood ↓ / Impact → | 1 Negligible | 2 Minor | 3 Moderate | 4 Major | 5 Catastrophic |
| ----------------------- | :----------: | :-----: | :--------: | :-----: | :------------: |
| 5 Almost Certain        |      5       |   10    |     15     |   20    |     **25**     |
| 4 Likely                |      4       |    8    |     12     | **16**  |     **20**     |
| 3 Possible              |      3       |    6    |     9      |   12    |       15       |
| 2 Unlikely              |      2       |    4    |     6      |    8    |       10       |
| 1 Rare                  |      1       |    2    |     3      |    4    |       5        |
 
## Risk Bands and Required Response
 
| Band     | Score Range | Color  | Required Action                                     |
| -------- | ----------- | ------ | --------------------------------------------------- |
| Critical | 20–25       | Red    | Immediate treatment required; escalate to CEO/board |
| High     | 12–19       | Orange | Treatment plan required within 30 days              |
| Medium   | 6–11        | Yellow | Treatment plan required within 90 days              |
| Low      | 1–5         | Green  | Accept or monitor; review annually                  |
 
## AcmeSoft Risk Register Scores (from Example 5)
 
| Risk ID  | Score | Band     | Action Required                            |
| -------- | ----- | -------- | ------------------------------------------ |
| RISK-001 | 20    | Critical | Immediate: rotate and vault DB credentials |
| RISK-005 | 16    | High     | 30 days: implement rate limiting + MFA     |
| RISK-003 | 10    | Medium   | 90 days: implement least-privilege IAM     |
| RISK-002 | 9     | Medium   | 90 days: enforce MDM disk encryption       |
| RISK-004 | 8     | Medium   | 90 days: vendor security assessment        |

# AcmeSoft Risk Treatment Decisions
# Owner: CISO | Approved by: Steering Committee | Date: 2026-05-21
 
treatment_options:
  # => MITIGATE: Implement controls to reduce likelihood or impact
  - risk_id: RISK-001
    option: Mitigate
    rationale: >
      Credential exposure is directly controllable via secrets management.
      Cost of breach (GDPR fine + churn) far exceeds control cost.
    # => Mitigate is appropriate when: control cost < expected loss × probability
    actions:
      - "Migrate all secrets to AWS Secrets Manager within 14 days"
      - "Rotate all existing database credentials immediately"
      - "Add pre-commit hook to scan for hardcoded secrets (detect-secrets)"
    residual_risk_score: 4 # => Score after controls applied (was 20)
    cost_estimate_usd: 3000
 
  # => TRANSFER: Shift financial consequence to a third party (insurance/contract)
  - risk_id: RISK-004
    option: Transfer
    rationale: >
      Supply chain risk from PayrollCo cannot be fully controlled — they
      own their own security posture. Cyber insurance covers breach costs.
    # => Transfer is appropriate when: risk source is external and you cannot eliminate it
    actions:
      - "Add security requirements clause to PayrollCo contract at renewal"
      - "Ensure cyber insurance policy covers third-party breach scenarios"
      - "Request PayrollCo's SOC 2 Type II report annually"
    residual_risk_score: 4 # => Insurance reduces financial impact; likelihood unchanged
    cost_estimate_usd: 8000 # => Annual cyber insurance premium increase
 
  # => ACCEPT: Acknowledge the risk and choose not to act
  - risk_id: RISK-002
    option: Accept
    rationale: >
      MDM rollout planned for Q3 as part of IT modernization. Interim
      accept is justified; all laptops have remote-wipe capability.
    # => Accept is appropriate when: cost of control > expected loss OR remediation is already planned
    review_date: "2026-08-01" # => Accepted risks MUST have a review date
    residual_risk_score: 9 # => No change — risk unchanged by acceptance
 
  # => AVOID: Eliminate the risk by stopping the risky activity
  - risk_id: RISK-003
    option: Avoid # => partially — we cannot avoid AWS entirely
    rationale: >
      Blanket admin access is unnecessary. Eliminating it removes the
      insider-misuse vector without stopping legitimate operations.
    # => Avoid is appropriate when: the activity creating risk can be stopped or redesigned
    actions:
      - "Remove admin IAM policies from all non-CISO engineers within 30 days"
      - "Implement role-based IAM with least privilege"
      - "Require break-glass procedure for emergency admin access"
    residual_risk_score: 3
    cost_estimate_usd: 2000

# Risk Treatment Plan: RISK-001
 
# Risk: DB credential exposure | Score: 20 (Critical) | Treatment: Mitigate
 
# Owner: Engineering Lead | Approved by: CISO | Date: 2026-05-21
 
## 1. Risk Summary
 
# => Restate the risk so readers do not need to cross-reference the register
 
Asset: Customer PII database (PostgreSQL, AWS RDS)
Threat: External attacker exfiltrates customer records via exposed credentials
Vulnerability: Database credentials stored in plaintext in application config files
Current Score: 20 (Critical) — requires immediate action
 
## 2. Treatment Objective
 
# => Define what "done" looks like in measurable terms
 
Reduce risk score from 20 (Critical) to ≤ 6 (Medium) by eliminating
plaintext credential storage and rotating all existing credentials.
 
## 3. Action Plan
 
# => Each task must have: description, owner, due date, and completion evidence
 
| Task | Description                                                 | Owner        | Due Date   | Evidence of Completion                 |
| ---- | ----------------------------------------------------------- | ------------ | ---------- | -------------------------------------- |
| T-01 | Audit all repos for hardcoded secrets (detect-secrets scan) | Sec Engineer | 2026-05-23 | Scan report with zero findings         |
| T-02 | Rotate all current database credentials                     | DBA          | 2026-05-24 | AWS RDS credential rotation log        |
| T-03 | Migrate app to use AWS Secrets Manager for DB credentials   | Backend Lead | 2026-05-28 | Code PR merged; no plaintext in config |
| T-04 | Add detect-secrets pre-commit hook to all repos             | DevEx Lead   | 2026-05-28 | Hook running in CI for all repos       |
| T-05 | Verify residual risk score and close treatment plan         | CISO         | 2026-05-30 | Updated risk register entry            |
 
## 4. Residual Risk Assessment
 
# => Document the expected risk score AFTER all controls are implemented
 
Expected residual score: 4 (Low)
 
# => Likelihood drops from 4 → 1 (secrets vaulted, rotation automated)
 
# => Impact remains 5 (data is still sensitive — classification unchanged)
 
Residual = Likelihood 1 × Impact 4 = 4 (Low)
 
# => Note: impact cannot be reduced without changing what data is stored
 
## 5. Escalation Path
 
# => What happens if tasks slip?
 
If T-03 is not completed by 2026-05-28: escalate to CTO and freeze
new feature deployments until remediation is complete.
 
## 6. Status
 
# => Treatment plans must show current progress
 
Current status: IN PROGRESS | Last updated: 2026-05-21

# AcmeSoft Security Awareness Training Program
# Owner: CISO | Cycle: Annual | Classification: Internal
 
program:
  name: "AcmeSoft Security Awareness Program 2026"
  objective: >
    Reduce successful phishing rate from current baseline to < 5%
    and achieve 100% policy acknowledgement by year end.
  # => Measurable objective — links training to a KPI (see Example 24)
  audiences:
    # => Segment by role — generic training has lower retention
    - name: All Staff
      size: 200
      required_modules: [foundations, phishing, passwords, data_handling]
 
    - name: Engineering
      size: 60
      required_modules: [foundations, phishing, passwords, data_handling, secure_coding, cloud_security]
      # => Developers need role-specific content on OWASP Top 10 etc.
 
    - name: Finance & HR
      size: 20
      required_modules: [foundations, phishing, passwords, data_handling, social_engineering, insider_threat]
      # => High-value targets for BEC and insider threat scenarios
 
    - name: Leadership (C-suite + Directors)
      size: 12
      required_modules: [executive_cybersecurity_briefing, bec_whaling]
      # => Executives need shorter, scenario-based content — not 40-min generic courses
 
  modules:
    - id: foundations
      title: "Security Fundamentals"
      duration_minutes: 20
      # => Keep under 30 min — completion rates drop sharply above this threshold
      topics: [CIA triad, classification labels, your responsibilities]
      frequency: annual
      delivery: async_elearning
      assessment: 10_question_quiz # => Minimum 80% pass score required
 
    - id: phishing
      title: "Recognizing Phishing and Social Engineering"
      duration_minutes: 15
      topics: [email red flags, link inspection, reporting procedure]
      frequency: annual_plus_simulations
      # => Simulations run quarterly (see Example 10)
      delivery: async_elearning
      assessment: scenario_quiz
 
    - id: data_handling
      title: "Data Classification and Handling"
      duration_minutes: 15
      topics: [classification levels, storage rules, sharing rules, disposal]
      frequency: annual
      delivery: async_elearning
      assessment: scenario_quiz
 
    - id: secure_coding
      title: "Secure Coding Fundamentals (Engineering only)"
      duration_minutes: 30
      topics: [OWASP Top 10, input validation, secrets management, dependency scanning]
      frequency: annual
      delivery: async_elearning_plus_live_workshop
      assessment: code_review_exercise
 
  schedule:
    - month: January
      activity: "Launch annual training; all staff assigned modules in LMS"
    - month: February
      activity: "Q1 phishing simulation (baseline)"
    - month: March
      activity: "Completion deadline; non-completers escalated to managers"
    - month: May
      activity: "Q2 phishing simulation; compare to Q1 baseline"
    - month: August
      activity: "Q3 phishing simulation; targeted retraining for clickers"
    - month: November
      activity: "Q4 phishing simulation; annual program review"
 
  metrics:
    # => Track these to demonstrate program effectiveness to leadership
    - "Training completion rate (target: 100%)"
    - "Phishing simulation click rate (target: < 5%)"
    - "Phishing report rate (target: > 60% of simulations reported)"
    - "Mean time to report a suspicious email (target: < 30 minutes)"

# AcmeSoft Phishing Simulation Campaign — Q1 2026
 
# Owner: CISO | Platform: GoPhish (self-hosted) | Classification: Confidential
 
## Phase 1: Baseline Measurement (Week 1)
 
# => Establish current susceptibility before any targeted training
 
Simulation parameters:
 
- Template: Generic credential-harvesting email ("IT: Verify your password")
  # => Start with a realistic but not highly sophisticated lure
- Target group: All 200 staff (blind — no pre-warning given)
  # => Pre-warning defeats the purpose of baseline measurement
- Tracking: Click rate, credential submission rate, report rate
- Duration: 72 hours open
 
Expected baseline (industry average for untrained orgs): 25–35% click rate
 
## Phase 2: Immediate Feedback Loop (Day 3)
 
# => Users who click see educational content immediately — no shaming
 
On click:
 
- Redirect to: internal landing page
  # => "You were just phished! Here is what you missed:"
- Show: 3 red flags in the email (sender domain, urgency language, hover URL)
- Link to: 5-minute refresher video on phishing recognition
- Log: username and click timestamp (for metrics, not public shaming)
 
## Phase 3: Targeted Training (Weeks 2–4)
 
# => Clickers receive additional training; non-clickers are not penalized
 
Clickers (>5% click rate cohort):
 
- Assigned: additional 15-minute phishing module in LMS
  # => Targeted, not punitive — frame as "we want to help you"
- Manager: informed only if employee clicks in 3+ consecutive simulations
  # => Escalation threshold prevents disproportionate response to single lapse
 
All staff:
 
- Monthly newsletter tip on current phishing trends
  # => Keeps awareness alive between formal training cycles
 
## Phase 4: Re-Test (Month 2)
 
# => Measure impact of training with a new simulation
 
Simulation parameters:
 
- Template: More sophisticated — spear-phish using real employee name
  # => Gradually increase sophistication each quarter
- Target group: Full staff + oversampled prior clickers
 
## Phase 5: Measurement and Reporting (End of Quarter)
 
# => Report metrics to leadership — connect training investment to outcome
 
| Metric                 | Q1 Baseline | Q1 Re-test | Target |
| ---------------------- | ----------- | ---------- | ------ |
| Click rate             | 28%         | 14%        | < 5%   |
| Credential submit rate | 12%         | 4%         | < 1%   |
| Report rate            | 8%          | 22%        | > 60%  |
 
# => Report rate is often more important than click rate — vigilant reporters
 
# => catch real attacks before they cause harm
 
## Ethical and Legal Requirements
 
# => Document these before launching any simulation
 
- [ ] Legal/HR sign-off obtained before first campaign
  # => Required in many jurisdictions; employees cannot be disciplined
  # => without prior notice that simulations may occur
- [ ] Policy states simulations may occur (AUP reference: Section 5)
- [ ] No personally identifiable click data shared outside security team
- [ ] Results used for training, not performance reviews

# AcmeSoft Incident Response Plan v1.0
 
# Owner: CISO | Last tested: 2026-05-21 | Classification: Confidential
 
## Phase 1: Preparation
 
# => Everything you do BEFORE an incident — most teams skip this phase
 
- Incident Response Team (IRT) roster with 24/7 contact numbers
- Defined severity classification (see table below)
- Pre-approved isolation procedures (no waiting for manager approval during attack)
- Forensic tooling pre-installed (disk imaging, memory capture)
- Legal counsel contact on retainer
- Cyber insurance policy number and claims hotline posted in IRT Slack channel
 
Severity Classification:
| Level | Definition | Example |
|-------|---------------------------------------------|--------------------------------|
| P1 | Active attack; data exfiltration in progress | Ransomware, live intrusion |
| P2 | Contained compromise; potential data at risk | Phishing with credential theft |
| P3 | Security event; no confirmed compromise | Failed login spike, malware alert |
| P4 | Informational; no impact | Policy violation, lost laptop |
 
## Phase 2: Detection and Analysis
 
# => How you know something is happening
 
Detection sources:
 
- SIEM alerts (Datadog Security) # => Log correlation, anomaly detection
- EDR alerts (CrowdStrike) # => Endpoint behavioral detection
- Employee reports (security@acmesoft.com) # => Human-layer detection
- Vendor notifications (AWS GuardDuty) # => Cloud threat detection
 
Initial triage checklist (complete within 30 minutes of alert):
 
- [ ] Confirm this is a genuine incident (not a false positive)
- [ ] Assign severity level (P1–P4)
- [ ] Notify IRT lead and CISO
- [ ] Open incident ticket in Jira (project: SEC-INC)
- [ ] Begin evidence collection (do not power off systems without imaging first)
 
## Phase 3: Containment
 
# => Stop the bleeding — do NOT prioritize cleanup over containment
 
Short-term containment (P1 — within 1 hour):
 
- Isolate affected systems from network (VLAN isolation or physical disconnect)
- Revoke compromised credentials immediately
- Preserve forensic evidence BEFORE containment actions
  # => Sequence matters: evidence first, then isolation — not the other way around
 
Long-term containment (after initial isolation):
 
- Deploy clean replacement systems in parallel
- Apply emergency patches to contain vulnerability class
- Enable enhanced monitoring on adjacent systems
 
## Phase 4: Eradication
 
# => Remove the threat completely before returning to production
 
- Identify root cause (required — cannot skip to recovery)
  # => "We removed the malware" is not eradication — root cause must be addressed
- Remove malware, backdoors, and attacker persistence mechanisms
- Patch exploited vulnerability
- Rotate all credentials that were in scope
 
## Phase 5: Recovery
 
# => Restore to normal operations safely
 
- Restore from last known-good backup
  # => Verify backup integrity BEFORE restoring — ransomware often targets backups
- Conduct staged re-introduction to production (dev → staging → prod)
- Enhanced monitoring for 30 days post-recovery
- Confirm business operations normal with impacted teams
 
## Phase 6: Lessons Learned
 
# => This phase is skipped most often — and produces the most value
 
Required within 2 weeks of incident closure:
 
- [ ] Post-incident review meeting (IRT + impacted teams)
- [ ] Root cause analysis document
- [ ] Action items with owners and due dates
- [ ] Update to this IR plan if gaps discovered
- [ ] Update risk register if new risks identified
- [ ] Board/leadership notification if P1 or P2 incident

# Nexatech Business Continuity Plan — Core Module
 
# Owner: CISO + COO | Review: Annual | Classification: Confidential
 
## Definitions
 
# => Define these terms once — avoid confusion in a real incident
 
RTO (Recovery Time Objective):
The maximum acceptable time between a disruption and restoration of service.
 
# => Set by the business based on revenue impact and SLA commitments
 
# => Example: RTO = 4 hours means we must be back online within 4 hours
 
RPO (Recovery Point Objective):
The maximum acceptable amount of data loss measured in time.
 
# => Set by the business based on transaction value and compliance
 
# => Example: RPO = 1 hour means we can lose up to 1 hour of transactions
 
## Business Impact Analysis (BIA)
 
# => Rank critical functions by their tolerance for disruption
 
| Business Function         | Systems Involved        | RTO                                 | RPO    | Financial Impact/Hour Down | Priority |
| ------------------------- | ----------------------- | ----------------------------------- | ------ | -------------------------- | -------- |
| Payment processing        | payment-api, PostgreSQL | 1 hr                                | 15 min | $45,000                    | P1       |
| Customer authentication   | auth-service, Redis     | 2 hrs                               | 30 min | $12,000                    | P1       |
| Merchant portal           | portal-web, portal-api  | 4 hrs                               | 1 hr   | $3,000                     | P2       |
| Internal reporting        | analytics-db, Metabase  | 24 hrs                              | 4 hrs  | $500                       | P3       |
| Email (internal)          | Google Workspace        | 8 hrs                               | N/A    | Low (operational friction) | P3       |
| # => P1: mission-critical | P2: important           | P3: can operate manually short-term |
 
## Recovery Strategies by Priority
 
P1 Systems — Payment Processing & Auth:
 
# => Must meet aggressive RTO/RPO; invest in high-availability architecture
 
- Active-active multi-AZ deployment (AWS ap-southeast-1 + ap-southeast-3)
- Database: AWS Aurora with 15-minute automated backups + PITR
  # => PITR (Point-in-Time Recovery) enables RPO of ~5 min in practice
- Automated failover: Route 53 health checks with 60-second failover
- Runbook: [RUNBOOK-P1-PAYMENT] — tested quarterly
 
P2 Systems — Merchant Portal:
 
- Active-passive: standby instance in secondary AZ, manual promotion
- RDS snapshot every hour; restore target: 4-hour RTO achievable
- Runbook: [RUNBOOK-P2-PORTAL]
 
P3 Systems — Internal Tools:
 
- Accept downtime; notify staff and use manual workarounds
- Restore from most recent daily backup when convenient
 
## BCP Testing Schedule
 
# => A plan that has never been tested is not a plan
 
| Test Type             | Frequency   | Last Run   | Next Run   | Owner      |
| --------------------- | ----------- | ---------- | ---------- | ---------- |
| Tabletop exercise     | Quarterly   | 2026-03-01 | 2026-06-01 | CISO       |
| Partial failover (P1) | Semi-annual | 2026-01-15 | 2026-07-15 | Infra Lead |
| Full DR test          | Annual      | 2025-11-01 | 2026-11-01 | CISO + COO |

# AcmeSoft Vendor Security Assessment Questionnaire
 
# Vendor: DataStore Co. | Assessor: CISO | Date: 2026-05-21
 
## Scoring Guide
 
# => Standardize scoring before sending — removes assessor subjectivity
 
| Score | Criteria                                              |
| ----- | ----------------------------------------------------- |
| 2     | Fully satisfied: evidence provided, meets requirement |
| 1     | Partially satisfied: practice exists but gaps present |
| 0     | Not satisfied: requirement not met or no evidence     |
| N/A   | Not applicable to this vendor's service scope         |
 
## Questions
 
1. Information Security Program
   Question: Do you have a documented Information Security Policy approved
   by senior management?
 
   # => Checks governance foundation — no policy = immature program
 
   Evidence requested: Policy document (or summary) + approval record
   Vendor response: **\*\***\_\_\_**\*\***
   Score: **\_ Assessor notes: \*\*\*\***\_**\*\*\*\***
 
2. Certifications and Audits
   Question: Do you hold current ISO 27001, SOC 2 Type II, or equivalent
   certification?
 
   # => Third-party audits provide stronger assurance than self-attestation
 
   Evidence requested: Current certificate or audit report (issued < 12 months)
   Vendor response: **\*\***\_\_\_**\*\***
   Score: \_\_\_
 
3. Data Encryption
   Question: Is AcmeSoft data encrypted at rest (AES-256 or equivalent)
   and in transit (TLS 1.2+)?
 
   # => Non-negotiable for any vendor handling Confidential or Restricted data
 
   Evidence requested: Technical architecture doc or security whitepaper
   Vendor response: **\*\***\_\_\_**\*\***
   Score: \_\_\_
 
4. Access Control
   Question: Is access to AcmeSoft data restricted to named individuals
   with documented business justification? Is MFA enforced?
   Evidence requested: Access control policy + sample access matrix
   Vendor response: **\*\***\_\_\_**\*\***
   Score: \_\_\_
 
5. Incident Response
   Question: Do you have a documented IR plan? What is your committed
   notification timeline for breaches affecting our data?
 
   # => GDPR requires 72-hour notification — vendor must support this
 
   Evidence requested: IR plan summary + breach notification SLA
   Vendor response: **\*\***\_\_\_**\*\***
   Score: \_\_\_
 
6. Subprocessors and Fourth Parties
   Question: Do you use subprocessors who will have access to AcmeSoft data?
   If yes, are they assessed against equivalent standards?
 
   # => Supply chain risk — your vendor's vendor is your risk too
 
   Evidence requested: Subprocessor list + assessment evidence
   Vendor response: **\*\***\_\_\_**\*\***
   Score: \_\_\_
 
7. Vulnerability Management
   Question: Do you have a formal vulnerability management program?
   What is your SLA for patching critical vulnerabilities?
   Evidence requested: Vulnerability management policy + patch SLA
   Vendor response: **\*\***\_\_\_**\*\***
   Score: \_\_\_
 
8. Data Residency
   Question: In which countries/regions will AcmeSoft data be stored
   and processed?
 
   # => GDPR restricts transfers outside EEA; some industries have data
 
   # => sovereignty requirements
 
   Evidence requested: Data residency statement
   Vendor response: **\*\***\_\_\_**\*\***
   Score: \_\_\_
 
9. Business Continuity
   Question: What is your RTO and RPO for your core service?
   When was your last DR test?
   Evidence requested: BCP summary + most recent DR test results
   Vendor response: **\*\***\_\_\_**\*\***
   Score: \_\_\_
 
10. Data Deletion
    Question: Upon contract termination, how is AcmeSoft data securely
    deleted, and can you provide a certificate of deletion?
    # => Right to erasure (GDPR Art. 17) — must be contractually guaranteed
    Evidence requested: Data deletion procedure + sample certificate
    Vendor response: **\*\***\_\_\_**\*\***
    Score: \_\_\_
 
## Scoring Summary
 
Total possible: 20 points
| Band | Score | Decision |
|--------------|-------|------------------------------------|
| Approved | 16–20 | Proceed with standard contract |
| Conditional | 10–15 | Proceed with remediation plan |
| Rejected | 0–9 | Do not proceed; seek alternative |

# AcmeSoft Third-Party Risk Tiering Model
# Owner: CISO | Applied to: all new and existing vendors
 
tiering_criteria:
  # => Two dimensions determine tier: data_access + operational_criticality
 
  data_access_levels:
    none: "Vendor has no access to AcmeSoft data"
    # => Example: office supplies, physical security firm
    metadata_only: "Vendor sees non-sensitive operational metadata only"
    # => Example: web analytics (anonymized), uptime monitoring
    internal: "Vendor accesses Internal-classified data"
    # => Example: project management SaaS, internal wiki platform
    confidential: "Vendor accesses Confidential data (customer PII, source code)"
    # => Example: customer support platform, background check provider
    restricted: "Vendor accesses Restricted data (PCI card data, HR records)"
    # => Example: payroll processor, payment gateway
 
  operational_criticality:
    low: "Outage has no impact on AcmeSoft revenue or operations"
    medium: "Outage causes operational friction but no revenue impact"
    high: "Outage directly impacts product availability or revenue"
 
tiers:
  - tier: 1
    label: "Critical"
    # => Highest scrutiny — full VSA + annual review
    criteria: "data_access IN [confidential, restricted] OR criticality = high"
    assessment: "Full VSA (Example 13) + legal review + annual reassessment"
    contract_requirements:
      - "Security Addendum with right-to-audit clause"
      - "Breach notification SLA ≤ 24 hours"
      - "Cyber insurance minimum $5M required"
      - "Annual SOC 2 Type II or ISO 27001 certificate required"
    examples: ["PayrollCo (HR data)", "AWS (infrastructure)", "Stripe (payments)"]
    acmesoft_vendor_count: 8
 
  - tier: 2
    label: "High"
    # => Standard scrutiny — abbreviated VSA + biennial review
    criteria: "data_access = internal AND criticality IN [medium, high]"
    assessment: "Abbreviated VSA (10 key questions) + legal contract review"
    contract_requirements:
      - "Data Processing Agreement (DPA) if personal data involved"
      - "Breach notification SLA ≤ 72 hours"
      - "Security certifications preferred but not required"
    examples: ["Jira (project mgmt)", "Slack (comms)", "GitHub (source code)"]
    acmesoft_vendor_count: 15
 
  - tier: 3
    label: "Standard"
    # => Light scrutiny — self-attestation + contract review
    criteria: "data_access IN [none, metadata_only] AND criticality = low"
    assessment: "Security questionnaire (5 questions) + standard contract terms"
    contract_requirements:
      - "Standard vendor terms with data protection clause"
    examples: ["Office supplies", "Travel booking", "Web fonts CDN"]
    acmesoft_vendor_count: 24
 
review_schedule:
  tier_1: annual # => Highest risk — reassess every 12 months
  tier_2: biennial # => Reassess every 24 months or on contract renewal
  tier_3: on_change # => Reassess only if data access or criticality changes
  # => Track review dates in vendor register to prevent drift

# Nexatech Security Governance Committee Charter
 
# Version: 1.0 | Approved by: CEO | Date: 2026-05-21
 
## 1. Purpose
 
# => Why does this committee exist? One clear sentence.
 
The Security Governance Committee (SGC) provides executive oversight of
Nexatech's information security program, ensuring security risk is managed
within board-approved risk tolerance and aligned with business objectives.
 
## 2. Authority
 
# => Define what the committee can decide without escalating to the board
 
The SGC is authorized to:
 
- Approve and revoke security policies
- Accept residual risks scoring 12–19 (High band) — see risk matrix
  # => Risks scoring 20+ require board approval; SGC cannot accept alone
- Approve security budget reallocations up to $50,000
- Mandate remediation timelines for High/Critical risks
- Approve security exceptions (see Example 26)
 
The SGC must escalate to the Board:
 
- Risks scoring 20+ (Critical band)
- Budget requests > $50,000
- Material breaches requiring public disclosure
 
## 3. Membership
 
# => Fixed composition — prevent the committee from expanding to ineffectiveness
 
| Role     | Member          | Vote | Rationale                        |
| -------- | --------------- | ---- | -------------------------------- |
| Chair    | CISO            | Yes  | Program ownership                |
| Co-Chair | CTO             | Yes  | Technical authority              |
| Member   | CFO             | Yes  | Financial and risk perspective   |
| Member   | COO             | Yes  | Operational continuity           |
| Member   | General Counsel | Yes  | Legal and compliance perspective |
| Advisor  | VP Engineering  | No   | Technical input; no vote         |
| Advisor  | VP People (HR)  | No   | People and policy perspective    |
 
# => Quorum: 3 voting members required for binding decisions
 
## 4. Meeting Cadence
 
# => Frequency must match risk velocity of the organization
 
| Meeting Type     | Frequency | Duration | Purpose                         |
| ---------------- | --------- | -------- | ------------------------------- |
| Regular          | Monthly   | 60 min   | Risk review, metrics, approvals |
| Quarterly review | Quarterly | 120 min  | Roadmap review, budget review   |
| Emergency        | Ad hoc    | 30 min   | P1/P2 incidents, critical risks |
 
# => Emergency meeting: any voting member can convene within 24 hours
 
## 5. Standing Agenda (Regular Meeting)
 
# => Consistent agenda reduces prep time and ensures nothing is missed
 
1. Previous minutes and action item review (10 min)
2. Security metrics dashboard review (15 min) — see Example 24
3. Risk register updates — new, changed, or closed risks (15 min)
4. Policy approvals or exceptions (10 min)
5. Incident review — any P1/P2 since last meeting (5 min)
6. Open items and next meeting date (5 min)
 
## 6. Reporting
 
# => Committee must report upward — create accountability chain
 
- Monthly: summary metrics to CEO
- Quarterly: risk posture report to board (see Example 25)
- Annually: security program review to board

# AcmeSoft Information Security Budget Request FY2027
 
# Prepared by: CISO | Presented to: CFO, CEO | Date: 2026-05-21
 
## Executive Summary
 
# => Lead with the business case, not the technology
 
Current exposure: 3 Critical risks and 5 High risks in the risk register
represent an estimated annualized loss expectancy (ALE) of $2.1M.
Proposed investment of $180K reduces ALE by approximately $1.4M (67%),
delivering a projected ROI of 7.8x over 12 months.
 
# => ROI framing: (risk reduction) / (investment) = (1,400,000) / (180,000) = 7.8x
 
## Budget Breakdown
 
| Initiative                                     | Risk Addressed               | Cost (USD) | Risk Reduction                 | Priority |
| ---------------------------------------------- | ---------------------------- | ---------- | ------------------------------ | -------- |
| Secrets management platform (HashiCorp Vault)  | RISK-001 (DB creds)          | $12,000/yr | 20 → 4 (Critical → Low)        | P1       |
| MDM platform (Jamf) — 200 devices              | RISK-002 (laptop encryption) | $18,000/yr | 9 → 2 (Medium → Low)           | P1       |
| SIEM + EDR (CrowdStrike + Datadog Security)    | Detection capability gap     | $65,000/yr | Enables P1 incident detection  | P1       |
| Penetration test (annual, external)            | Unknown vulnerabilities      | $25,000    | Identifies RISK-001 class gaps | P1       |
| Security awareness training platform (KnowBe4) | Phishing (RISK-005 related)  | $15,000/yr | 28% → <5% phish click rate     | P2       |
| Cyber insurance premium increase               | RISK-004 (supply chain)      | $20,000/yr | Transfer $2M risk to insurer   | P2       |
| CISO fractional + program management           | Program continuity           | $25,000/yr | Ongoing governance             | P2       |
 
# => Note: Items without /yr are one-time costs in FY2027 only
 
Total: $180,000
 
# => Of which recurring (annual): $155,000 | One-time: $25,000
 
## Risk Without This Investment
 
# => Show the cost of NOT investing — this is the most persuasive section
 
If budget is not approved:
 
- RISK-001 (Critical, ALE $800K) remains unremediated
- No detection capability: mean time to detect breach remains > 200 days
  # => Industry average for orgs without SIEM/EDR: 204 days (IBM Cost of Breach report)
- Cyber insurance renewal at risk if MDM gap not closed (insurer flagged in last review)
- SOC 2 Type II audit (required by 3 enterprise customers) will fail without SIEM evidence
 
## Request
 
Approve $180,000 FY2027 security budget.
Decision needed by: 2026-06-15 (vendor procurement lead times require early start)

# AcmeSoft Security Roadmap FY2027
 
# Owner: CISO | Approved: 2026-06-01 | Review: Quarterly
 
## Roadmap Principles
 
# => State the sequencing logic so stakeholders understand prioritization
 
1. Critical risks before High risks before Medium risks
2. Detection capability (SIEM/EDR) before response capability (IR plan testing)
   # => You cannot respond to what you cannot see
3. Foundation (policy, classification) before certification (SOC 2)
   # => Auditors check foundations first; building on gaps wastes certification spend
 
## 12-Month Initiatives
 
| Quarter      | Initiative                                      | Risk(s) Addressed     | Owner      | Success Criteria                                                  | Status  |
| ------------ | ----------------------------------------------- | --------------------- | ---------- | ----------------------------------------------------------------- | ------- |
| Q1 (Jun–Aug) | Secrets management rollout (HashiCorp Vault)    | RISK-001              | Eng Lead   | Zero hardcoded secrets in CI scan; RISK-001 closed                | Planned |
| Q1           | MDM deployment (Jamf, 200 devices)              | RISK-002              | IT Manager | 100% device enrollment; disk encryption enforced                  | Planned |
| Q1           | Security awareness training launch              | Phishing / human risk | CISO       | 100% staff enrolled; Q1 phish simulation baseline run             | Planned |
| Q2 (Sep–Nov) | SIEM deployment (Datadog Security)              | Detection gap         | Infra Lead | SIEM live; 10 core alert rules tuned; P1 runbook tested           | Planned |
| Q2           | EDR deployment (CrowdStrike, all endpoints)     | Detection gap         | IT Manager | 100% endpoint coverage; baseline behavioral policy active         | Planned |
| Q2           | Annual penetration test                         | Unknown vulns         | CISO       | Report received; all Critical/High findings have treatment plans  | Planned |
| Q3 (Dec–Feb) | Least-privilege IAM redesign (AWS)              | RISK-003              | Eng Lead   | No engineer has AWS admin; break-glass procedure tested           | Planned |
| Q3           | Incident response plan v2 + tabletop exercise   | IR capability         | CISO       | IR plan updated; tabletop completed; gaps documented              | Planned |
| Q3           | Vendor security assessment — all Tier 1 vendors | RISK-004              | CISO       | 8 Tier 1 VSAs completed; gaps tracked in risk register            | Planned |
| Q4 (Mar–May) | SOC 2 Type II readiness assessment              | Compliance            | CISO       | Readiness gaps identified; remediation plan to steering committee | Planned |
| Q4           | Security metrics dashboard (board reporting)    | Governance            | CISO       | Monthly board pack automated; 5 KPIs live (see Example 24)        | Planned |
| Q4           | Annual security program review                  | Program maturity      | CISO       | Maturity assessment complete; FY2028 roadmap drafted              | Planned |
 
## Dependencies and Risks
 
# => Proactively surface what could derail the roadmap
 
| Dependency                                       | Risk if not resolved  | Owner           | Target Date |
| ------------------------------------------------ | --------------------- | --------------- | ----------- |
| AWS architecture team bandwidth for IAM redesign | Q3 initiative delayed | CTO             | Aug 2026    |
| Legal review of Vault deployment (SaaS terms)    | Q1 initiative delayed | General Counsel | Jun 2026    |
| Pen test vendor selected and contracted          | Q2 initiative on time | CISO            | Jul 2026    |
 
## Quarterly Steering Committee Review Points
 
# => Build in review gates so the roadmap stays current
 
- Q1 review: Jun → Aug completion; Q2 scope confirmation
- Q2 review: Detection capability validation; pen test finding review
- Q3 review: SOC 2 decision point (proceed or defer to FY2028?)
- Q4 review: FY2027 close; FY2028 roadmap approval

# NIST CSF 2.0 — Govern Function Mapping
# Organization: Nexatech | Assessor: CISO | Date: 2026-05-21
 
function: Govern (GV)
# => Added in CSF 2.0 — not present in CSF 1.1
# => Purpose: Establish and monitor the organization's overall cybersecurity
# =>          risk management strategy, expectations, and policy
 
categories:
  - id: GV.OC
    name: Organizational Context
    # => Understand the circumstances of the organization that affect
    # => cybersecurity risk management decisions
    subcategories:
      - id: GV.OC-01
        description: "Organizational mission is understood and informs cybersecurity risk management"
        nexatech_current_state: "Partial — mission documented in BRD but not linked to risk appetite"
        practical_action: "Add a 'Security and Mission' section to the IS Policy (Example 4) linking payment integrity to CIA triad"
        maturity: 2 # => 1=Partial, 2=Risk-Informed, 3=Repeatable, 4=Adaptive
 
      - id: GV.OC-05
        description: "Outcomes, capabilities, and services that the organization depends on are understood"
        nexatech_current_state: "Partial — BIA table exists (Example 12) but not formally documented as CSF artifact"
        practical_action: "Promote BIA table to formal Organizational Context document; review annually"
        maturity: 2
 
  - id: GV.RM
    name: Risk Management Strategy
    # => Establish, communicate, and monitor the organization's cybersecurity risk strategy
    subcategories:
      - id: GV.RM-01
        description: "Risk management objectives are established and agreed to by organizational stakeholders"
        nexatech_current_state: "Partial — risk register exists (Example 5) but no formal risk appetite statement"
        practical_action: "Steering committee to adopt a formal risk appetite statement: 'Nexatech will not accept risks scoring 20+ without board approval'"
        maturity: 2
 
      - id: GV.RM-04
        description: "Strategic direction that describes appropriate risk response options is established"
        nexatech_current_state: "In progress — treatment decisions documented (Example 7) but no formal strategy"
        practical_action: "Document the four treatment options (Accept/Mitigate/Transfer/Avoid) as organizational policy with authority thresholds"
        maturity: 2
 
  - id: GV.RR
    name: Roles, Responsibilities, and Authorities
    subcategories:
      - id: GV.RR-01
        description: "Organizational leadership is responsible and accountable for cybersecurity risk"
        nexatech_current_state: "Established — IS Policy (Example 4) signed by CEO"
        practical_action: "Add cybersecurity KPIs to CEO and CISO annual performance objectives"
        maturity: 3
 
      - id: GV.RR-02
        description: "Roles, responsibilities, and authorities related to cybersecurity risk management are established"
        nexatech_current_state: "Established — SGC Charter (Example 15) documents roles"
        practical_action: "Publish RACI matrix for all security processes; include in onboarding"
        maturity: 3
 
  - id: GV.SC
    name: Supply Chain Risk Management
    # => New emphasis in CSF 2.0 — third-party risk elevated to Govern level
    subcategories:
      - id: GV.SC-01
        description: "A cybersecurity supply chain risk management program is established, approved, and communicated"
        nexatech_current_state: "Developing — tiering model (Example 14) defined but not yet a formal program"
        practical_action: "Formalize vendor tiering as a Supply Chain Risk Management Policy; present to SGC for approval"
        maturity: 1
 
nexatech_govern_maturity_summary:
  current_average: 2.1 # => Risk-Informed tier overall
  target_by_eoy: 3.0 # => Repeatable — documented, consistently applied
  gap_areas: ["Risk appetite statement", "Supply chain program formalization"]
  # => Focus Q3 roadmap efforts on these two gaps

# Nexatech ISMS Scope Statement
 
# Standard: ISO/IEC 27001:2022 | Clause reference: 4.3
 
# Owner: CISO | Approved by: CEO | Date: 2026-05-21
 
## ISMS Scope Statement
 
# => Must be precise — auditors will test that ALL in-scope assets are covered
 
# => and that scope exclusions are justified
 
IN SCOPE:
 
- All information systems supporting Nexatech's payment processing platform
- Customer PII processed through the payment API and stored in production databases
- Employee data stored in the HRIS system
- Nexatech offices: Headquarters (Jakarta) and remote workers (Indonesia only)
- Third-party cloud infrastructure (AWS ap-southeast-1) used to deliver services
- Key third-party processors: [PayrollCo, DataStore Co.]
  # => Must include key processors handling in-scope data
 
OUT OF SCOPE (with justification):
 
- Development and staging environments
  # => Justification: no real customer data; isolated from production by network controls
- Archived legacy systems (decommissioned 2024)
  # => Justification: no active data processing; access removed; documented decommission
 
---
 
# PDCA Cycle Applied to Nexatech ISMS
 
# => The PDCA cycle is the engine of ISO 27001 — it drives continual improvement
 
## PLAN (Clause 6–8)
 
# => Establish the ISMS framework and set objectives
 
Actions:
 
- Conduct risk assessment (Example 5) — identify all risks within scope
- Set risk treatment plan (Example 8) — decide how to treat each risk
- Define security objectives aligned with IS Policy (Example 4)
- Write and approve all required policies (Annex A controls) # => ISO 27001:2022 Annex A has 93 controls across 4 themes
  Outputs: Risk register, treatment plan, policy library, ISMS documentation set
  Nexatech status: IN PROGRESS (Q1 2027)
 
## DO (Clause 8)
 
# => Implement the controls and processes decided in Plan
 
Actions:
 
- Execute risk treatment plan (all tasks from Example 8)
- Deploy technical controls (SIEM, EDR, secrets management — roadmap Q1/Q2)
- Run awareness training (Example 9)
- Implement supplier security controls (Examples 13–14)
  Outputs: Evidence of control operation (logs, screenshots, records)
  Nexatech status: PLANNED (Q2–Q3 2027)
 
## CHECK (Clause 9)
 
# => Monitor and measure whether controls are working
 
Actions:
 
- Internal audit against all 93 Annex A controls
  # => Must be conducted by someone independent of the control owner
- Management review — SGC quarterly meeting (Example 15) covers this
- Security metrics review (Example 24)
- Penetration test (roadmap Q2)
  Outputs: Internal audit report, management review minutes, KPI dashboard
  Nexatech status: PLANNED (Q3 2027)
 
## ACT (Clause 10)
 
# => Improve based on Check findings
 
Actions:
 
- Address all internal audit nonconformities with corrective action plans
- Update risk register based on new threats identified
- Revise policies where gaps were found
- Prepare for certification audit (Stage 1: document review; Stage 2: on-site) # => Stage 1 typically 1 month before Stage 2
  Outputs: Corrective action log, updated ISMS documentation, certification
  Nexatech status: PLANNED (Q4 2027)

# AcmeSoft CIS Controls v8 — IG1 Implementation Status
 
# Framework: CIS Controls v8 | IG: 1 (Essential Hygiene) | Date: 2026-05-21
 
## What IG1 Covers
 
# => IG1 is designed for organizations with limited IT/security staff and expertise
 
# => Completing IG1 defends against ~85% of common attacks
 
| CIS Control | Name                                       | What It Means in Practice                                                                                       | AcmeSoft Status                                                         |
| ----------- | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| 1           | Inventory and Control of Enterprise Assets | Know every device on your network (laptops, servers, phones) — you cannot protect what you do not know exists   | Partial — laptops tracked in spreadsheet; cloud assets not inventoried  |
| 2           | Inventory and Control of Software Assets   | Know every application installed on company devices — unauthorized software = unauthorized risk                 | Not started — no MDM yet (see RISK-002)                                 |
| 3           | Data Protection                            | Classify data (Example 2), encrypt sensitive data at rest and in transit, implement DLP for most sensitive data | Partial — classification scheme defined; encryption inconsistent        |
| 4           | Secure Configuration of Enterprise Assets  | Apply hardened configurations to all devices and servers (CIS Benchmarks) — defaults are rarely secure          | Not started — no baseline hardening standard defined                    |
| 5           | Account Management                         | Maintain inventory of all accounts; disable accounts within 24 hours of termination; no shared accounts         | Partial — offboarding process exists but 24-hr SLA not met consistently |
| 6           | Access Control Management                  | Enforce least-privilege and need-to-know; use role-based access; review access quarterly                        | Partial — RBAC in most apps; no quarterly review process                |
| 7           | Continuous Vulnerability Management        | Scan for vulnerabilities weekly; patch critical vulns within 14 days                                            | Not started — no vulnerability scanner deployed                         |
| 8           | Audit Log Management                       | Enable logging on all systems; centralize logs; retain for 90+ days                                             | Partial — AWS CloudTrail enabled; application logs not centralized      |
| 9           | Email and Web Browser Protections          | Enable email filtering (anti-spam, anti-phish); use DNS filtering for web                                       | Partial — Google Workspace spam filter; no DNS filtering                |
| 10          | Malware Defenses                           | Deploy EDR/anti-malware on all endpoints; enable automatic updates                                              | Not started — no EDR (roadmap Q2)                                       |
| 11          | Data Recovery                              | Automate backups of critical data; test restores quarterly                                                      | Partial — RDS automated backups; restore not tested in 12 months        |
| 12          | Network Infrastructure Management          | Secure network devices (firewalls, switches); prohibit default passwords                                        | Partial — AWS security groups configured; no network device inventory   |
| 13          | Network Monitoring and Defense             | Deploy network-level monitoring; segment sensitive systems on separate VLANs                                    | Not started — no network monitoring; flat network architecture          |
| 14          | Security Awareness and Skills Training     | Annual security awareness training for all staff (Example 9)                                                    | In progress — program launched Q1 2027                                  |
| 15          | Service Provider Management                | Assess vendors; include security requirements in contracts (Examples 13–14)                                     | Partial — tiering model defined; VSAs not complete for all Tier 1       |
| 16          | Application Software Security              | Conduct code reviews; run SAST/DAST tools in CI/CD; patch third-party libraries                                 | Partial — dependency scanning via Dependabot; no SAST                   |
| 17          | Incident Response Management               | Maintain and test IR plan (Example 11)                                                                          | Partial — IR plan v1.0 drafted; not yet tested                          |
| 18          | Penetration Testing                        | Annual penetration test by qualified external party                                                             | Not started — scheduled Q2 2027 (roadmap)                               |
 
## IG1 Completion Summary
 
Completed: 0 controls (0%)
Partial: 10 controls (56%)
Not Started: 8 controls (44%)
 
# => Target: IG1 fully complete by end of FY2027 roadmap

# Nexatech SOC 2 Type II — Trust Services Criteria Overview
 
# Auditor: [TBD — external CPA firm] | Audit period: Jan 2027 – Jun 2027
 
# Classification: Confidential
 
## The Five Trust Services Criteria
 
### 1. Security (CC — Common Criteria)
 
# => REQUIRED in every SOC 2 report — the other four are optional
 
Definition: The system is protected against unauthorized access, use, or modification.
 
# => This is the broadest criteria — covers logical and physical access, change management, risk management
 
Example Evidence Nexatech Must Produce:
 
- Penetration test report (annual) with remediation evidence
- Access provisioning and deprovisioning records (user access reviews)
- Change management tickets showing security review before production deployments
- Incident log showing all P1/P2 incidents and their resolution
- Risk register with treatment status (Examples 5–8)
- Security awareness training completion records (Example 9)
 
### 2. Availability (A-series)
 
# => Optional but typically included for SaaS companies
 
Definition: The system is available for operation and use as committed or agreed.
 
Example Evidence Nexatech Must Produce:
 
- SLA documentation and uptime reports for audit period
- BCP and DR test results (Example 12)
- Incident tickets showing RTO was met for any outages
- Monitoring dashboards showing availability metrics
 
### 3. Processing Integrity (PI-series)
 
# => Optional — relevant for payment processors like Nexatech
 
Definition: System processing is complete, valid, accurate, timely, and authorized.
 
Example Evidence Nexatech Must Produce:
 
- Input validation controls documented in architecture docs
- Error handling and reconciliation procedures
- Transaction processing logs showing completeness checks
- Batch processing job completion logs
 
### 4. Confidentiality (C-series)
 
# => Optional — relevant when handling confidential third-party information
 
Definition: Information designated as confidential is protected as committed or agreed.
 
Example Evidence Nexatech Must Produce:
 
- Data classification policy and enforcement evidence (Example 2)
- Encryption implementation evidence (at rest and in transit)
- NDA records for all staff and contractors with confidential access
- Data flow diagrams showing where confidential data resides
 
### 5. Privacy (P-series)
 
# => Optional — relevant when handling personal information
 
Definition: Personal information is collected, used, retained, and disclosed in conformity with the entity's privacy notice.
 
Example Evidence Nexatech Must Produce:
 
- Privacy policy (customer-facing)
- Data processing agreements with all subprocessors
- Data subject request (DSR) handling procedure and sample tickets
- Retention schedule and deletion evidence
 
## Type I vs Type II Distinction
 
# => Customers always want Type II — it is stronger assurance
 
| Report Type | Coverage Period | What It Proves                                      | Typical Use                             |
| ----------- | --------------- | --------------------------------------------------- | --------------------------------------- |
| Type I      | Point in time   | Controls are suitably designed                      | Quick audit, first-time certification   |
| Type II     | 6–12 months     | Controls operated effectively throughout the period | Enterprise sales, regulatory compliance |
 
# => Type I says "we have good controls on paper"
 
# => Type II says "we actually ran those controls for 12 months with evidence"
 
## Nexatech SOC 2 Readiness Timeline
 
- Q3 2027: Readiness assessment (gap analysis against all CC criteria)
- Q3 2027: Remediate gaps identified in readiness assessment
- Jan 2027: Audit period begins (controls must be operational from day 1)
- Jun 2027: Audit period ends; auditor fieldwork begins
- Aug 2027: SOC 2 Type II report issued
  # => 12–16 weeks from fieldwork start to report issuance is typical

# AcmeSoft GDPR Compliance Checklist
# Jurisdiction: EU/EEA | Regulation: GDPR (Regulation EU 2016/679)
# Owner: CISO + General Counsel | Last reviewed: 2026-05-21
 
gdpr_obligations:
  - article: "Art. 5 — Data Processing Principles"
    # => The foundational principles — every other obligation flows from these
    obligations:
      - "Process personal data lawfully, fairly, and transparently"
      - "Collect data for specified, explicit, and legitimate purposes only (purpose limitation)"
      - "Collect only data necessary for the stated purpose (data minimisation)"
      - "Keep data accurate and up to date (accuracy)"
      - "Retain data only as long as necessary (storage limitation)"
      - "Process securely to ensure appropriate security (integrity and confidentiality)"
    acmesoft_gap: "No formal data retention schedule defined — storage limitation gap"
    action: "Create data retention schedule by 2026-07-01"
    owner: "CISO + Legal"
 
  - article: "Art. 6 — Lawful Basis for Processing"
    # => Every processing activity must have one of six lawful bases
    obligations:
      - "Document the lawful basis for every category of personal data processing"
    lawful_bases:
      - "Consent — user gave explicit consent (requires withdrawal mechanism)"
      - "Contract — processing necessary to perform a contract with the data subject"
        # => Most common basis for SaaS: processing customer data to deliver the service
      - "Legal obligation — required by law"
      - "Vital interests — life-or-death emergency"
      - "Public task — official authority"
      - "Legitimate interests — balanced against data subject rights"
    acmesoft_status: "Contract basis documented for customer data; consent flow needed for marketing"
    action: "Audit all processing activities in Records of Processing Activities (RoPA)"
 
  - article: "Art. 13–14 — Transparency (Privacy Notice)"
    obligations:
      - "Provide privacy notice to data subjects at time of collection"
      - "Include: identity of controller, purposes, lawful basis, retention periods, data subject rights"
    acmesoft_status: "Privacy policy exists but missing retention periods and lawful basis statements"
    action: "Update privacy policy to include all required Art. 13 elements by 2026-06-15"
 
  - article: "Art. 17 — Right to Erasure ('Right to be Forgotten')"
    obligations:
      - "Delete personal data on request when no longer necessary or consent withdrawn"
      - "Ensure deletion flows through to subprocessors"
    acmesoft_status: "No formal DSR (Data Subject Request) handling process"
    action: "Implement DSR intake form and 30-day response SLA; cascade to all subprocessors"
 
  - article: "Art. 28 — Data Processing Agreements (DPAs)"
    # => Required with EVERY vendor who processes personal data on your behalf
    obligations:
      - "Sign DPA with all processors (subprocessors) handling EU personal data"
      - "DPA must include security obligations, subprocessor rules, deletion requirements"
    acmesoft_status: "DPAs missing for 4 of 8 Tier 1 vendors"
    action: "Execute DPAs with all Tier 1 vendors by 2026-07-01"
    priority: HIGH
 
  - article: "Art. 32 — Security of Processing"
    obligations:
      - "Implement appropriate technical and organisational measures (TOMs)"
      - "Measures must be proportionate to risk"
    acmesoft_toms:
      - "Encryption of personal data at rest (AES-256) and in transit (TLS 1.2+)"
      - "Access controls and MFA for all systems processing personal data"
      - "Regular security testing (penetration test — roadmap Q2)"
      - "Staff training on data protection (awareness program — Example 9)"
    acmesoft_status: "TOMs partially implemented — encryption gaps remain"
 
  - article: "Art. 33 — Data Breach Notification (to Supervisory Authority)"
    # => 72-HOUR DEADLINE — the most time-critical GDPR obligation
    obligations:
      - "Notify lead supervisory authority within 72 hours of becoming aware of breach"
      - "Notification must include: nature of breach, categories affected, approximate number of records"
    acmesoft_status: "IR plan v1.0 includes 72-hr notification trigger; DPA authority not yet identified"
    action: "Identify lead supervisory authority (Art. 56 one-stop-shop); add to IR plan"
 
  - article: "Art. 30 — Records of Processing Activities (RoPA)"
    # => Required for all orgs with > 250 employees OR processing high-risk data
    obligations:
      - "Maintain written records of all processing activities"
      - "RoPA must include: purposes, categories of data, recipients, retention periods, security measures"
    acmesoft_status: "RoPA not started"
    action: "Complete RoPA for all processing activities by 2026-07-15"
    priority: HIGH

# Nexatech PCI DSS v4.0 — 12 Requirements Summary
 
# Scope: Cardholder Data Environment (CDE) | QSA: TBD | Assessment: Annual
 
## Scope Reduction First
 
# => Reducing PCI scope is the highest-value first action for any SaaS company
 
# => If you do not store, process, or transmit CHD, you are out of scope for that req
 
Nexatech scope reduction strategy:
 
- Use Stripe Elements (tokenization) — card numbers never touch Nexatech servers
  # => Card number (PAN) stays in Stripe's CDE; Nexatech receives only tokens
- Store only: last 4 digits, card brand, expiry month/year (permitted by PCI DSS)
- Result: significantly reduced CDE scope — assess with QSA before assuming
 
---
 
## The 12 Requirements
 
| Req | Goal                            | Name                                                                   | Nexatech Relevance                                                         | Status                           |
| --- | ------------------------------- | ---------------------------------------------------------------------- | -------------------------------------------------------------------------- | -------------------------------- |
| 1   | Build/Maintain Secure Network   | Install and maintain network security controls                         | AWS security groups restricting CDE traffic; firewall rules between zones  | Partial                          |
| 2   | Build/Maintain Secure Network   | Apply secure configurations to all system components                   | Default passwords changed; CDE components hardened per CIS Benchmarks      | Not Started                      |
| 3   | Protect CHD                     | Protect stored account data                                            | Nexatech stores only token + last 4 + expiry — no full PAN stored          | Complete (scope reduced)         |
| 4   | Protect CHD                     | Protect cardholder data with strong cryptography during transmission   | All API traffic over TLS 1.2+; Stripe handles card-to-token encryption     | Complete                         |
| 5   | Maintain Vulnerability Mgmt     | Protect all systems and networks from malicious software               | EDR deployment (roadmap Q2); patch management process needed               | Not Started                      |
| 6   | Maintain Vulnerability Mgmt     | Develop and maintain secure systems and software                       | SAST in CI/CD (partial); dependency scanning active; pen test (roadmap Q2) | Partial                          |
| 7   | Implement Strong Access Control | Restrict access to system components by business need                  | RBAC implemented in CDE systems; access reviews needed quarterly           | Partial                          |
| 8   | Implement Strong Access Control | Identify users and authenticate access to system components            | MFA enforced on CDE access; shared accounts prohibited                     | Partial                          |
| 9   | Implement Strong Access Control | Restrict physical access to cardholder data                            | CDE is cloud-only (AWS data centers); AWS physical security covers this    | Complete (cloud provider covers) |
| 10  | Regularly Monitor/Test          | Log and monitor all access to system components and CHD                | AWS CloudTrail + application logs; centralized SIEM needed (roadmap Q2)    | Partial                          |
| 11  | Regularly Monitor/Test          | Test security of systems and networks regularly                        | Annual pen test (roadmap Q2); quarterly internal scan needed               | Not Started                      |
| 12  | Maintain Info Security Policy   | Support information security with organizational policies and programs | IS Policy (Example 4); AUP (Example 3); awareness training (Example 9)     | Partial                          |
 
## PCI DSS Compliance Levels
 
# => Your level determines assessment type (self-assessment vs. on-site QSA audit)
 
| Level | Annual Transactions | Assessment Type          |
| ----- | ------------------- | ------------------------ |
| 1     | > 6 million         | Annual on-site QSA audit |
| 2     | 1–6 million         | Annual SAQ or QSA audit  |
| 3     | 20K–1 million       | Annual SAQ               |
| 4     | < 20K               | Annual SAQ (recommended) |
 
# => Nexatech current volume: ~150K transactions/year = Level 3
 
# => Complete SAQ D (most comprehensive SAQ) due to direct API processing
 
## Key PCI DSS v4.0 Changes (from v3.2.1)
 
# => v4.0 effective March 2024; new requirements effective March 2025
 
- Requirement 8: MFA now required for ALL access into the CDE (was: only admin)
  # => Action required: enforce MFA for ALL CDE user accounts
- Requirement 6: Web application firewall (WAF) or automated technical solution required
  # => Action required: deploy AWS WAF in front of payment API
- Requirement 12: Targeted risk analysis required for many requirements
  # => Action required: document formal risk analysis per req; update annually

# AcmeSoft Security KPI Dashboard Definition
# Audience: Board, CEO, CFO | Cadence: Monthly | Owner: CISO
 
kpis:
  - id: KPI-001
    name: "Mean Time to Detect (MTTD)"
    # => How long between an incident occurring and us knowing about it
    definition: "Average time from when a security incident begins to when the security team detects it"
    why_it_matters: "Longer detection = greater data exfiltration and breach cost; industry avg is 194 days"
    data_source: "Incident tickets (Jira SEC-INC project) — field: incident_start vs. detection_timestamp"
    formula: "SUM(detection_timestamp - incident_start) / COUNT(incidents) for the month"
    unit: hours
    target: "< 4 hours for P1/P2; < 24 hours for P3"
    current_value: "Not measurable yet — SIEM not deployed"
    # => Baseline after SIEM deployment (roadmap Q2)
    board_narrative: "Deployment of SIEM in Q2 will establish baseline; target is industry top quartile"
 
  - id: KPI-002
    name: "Critical/High Vulnerability Remediation Rate"
    # => Are we patching fast enough to stay ahead of attackers?
    definition: "Percentage of Critical and High vulnerabilities remediated within SLA"
    slas: { critical: "7 days", high: "30 days" }
    why_it_matters: "Unpatched critical vulnerabilities are the most exploited attack vector (CISA KEV)"
    data_source: "Vulnerability scanner output (once deployed) + Jira patch tickets"
    formula: "COUNT(vulns patched within SLA) / COUNT(vulns identified) × 100"
    unit: "percent"
    target: "> 95% of Critical within 7 days; > 90% of High within 30 days"
    current_value: "Not measurable — scanner not deployed"
 
  - id: KPI-003
    name: "Security Awareness Training Completion Rate"
    # => Simple operational metric — but 100% is genuinely non-trivial to achieve
    definition: "Percentage of all employees who have completed required annual security training modules"
    why_it_matters: "Untrained employees are the highest-probability entry point for phishing attacks"
    data_source: "LMS (Learning Management System) completion reports"
    formula: "COUNT(employees who completed all required modules) / COUNT(total employees) × 100"
    unit: "percent"
    target: "100% by March 31 each year"
    current_value: "68% (training launched January; non-completers escalated to managers)"
 
  - id: KPI-004
    name: "Phishing Simulation Click Rate"
    # => Behavioral metric — measures actual security behavior, not just knowledge
    definition: "Percentage of employees who click a link in quarterly phishing simulation emails"
    why_it_matters: "Directly measures susceptibility to the most common initial attack vector"
    data_source: "GoPhish simulation platform reports (quarterly)"
    formula: "COUNT(unique clickers) / COUNT(simulation targets) × 100"
    unit: "percent"
    target: "< 5% (industry top quartile for mature programs)"
    current_value: "28% (Q1 baseline — see Example 10)"
    trend: "Declining — 28% (Q1 baseline) → target 15% (Q2) → target 5% (Q4)"
    # => Report the trend, not just the point-in-time number
 
  - id: KPI-005
    name: "Risk Register Age — Open Critical/High Risks"
    # => Are known risks being treated, or just documented?
    definition: "Number of Critical and High risks open (without accepted treatment completion) and their average age in days"
    why_it_matters: "Stale high risks indicate the risk management process is not driving remediation"
    data_source: "Risk register (Confluence) — filter by status=open AND score>=12"
    formula: "COUNT(open Critical/High risks) AND AVG(today - risk_identified_date) for those risks"
    unit: "count + days"
    target: "0 Critical risks open > 14 days; 0 High risks open > 45 days"
    current_value: "1 Critical (RISK-001, 3 days old); 1 High (RISK-005, 3 days old)"
    board_narrative: "Treatment plans active for both; RISK-001 expected closed by May 24"
 
dashboard_note: >
  These five KPIs are reported monthly to the board in a one-page format (see Example 25).
  Each KPI shows: current value, previous month value, trend arrow, and RAG status.
  # => RAG: Red/Amber/Green status provides instant visual triage for board members

# AcmeSoft Security Risk Summary — Q1 2027
 
# Presented by: CISO | Date: 2026-05-21 | Audience: Board of Directors
 
---
 
## RISK POSTURE OVERVIEW
 
# => The heat map tells the whole story at a glance
 
```
 
        IMPACT →
        1-Neg  2-Min  3-Mod  4-Major  5-Cat
 
L 5 [ ][ ][ ][ ][ R001] ← RISK-001 was here (now closed)
I 4 [ ][ ][ R005][ ][ ]
K 3 [ ][ ][ R002][ ][ ]
E 2 [ ][ ][ ][ R004][ R003]
L 1 [ ][ ][ ][ ][ ]
I ↑
H
O
O
D
 
Legend: [RED=Critical 20-25] [ORANGE=High 12-19] [YELLOW=Medium 6-11] [GREEN=Low 1-5]
 
```
 
## HEADLINE: Risk posture improving
 
# => Lead with the narrative, then show the data
 
- 1 Critical risk CLOSED this quarter (RISK-001: database credentials — fully remediated)
- 0 Critical risks currently open
- 2 High risks in active treatment (RISK-005, RISK-003)
 
# => Board needs to know: are we getting better or worse? Answer first.
 
---
 
## TOP 3 OPEN RISKS
 
# => Name the risks, state what is being done, state when they will be resolved
 
| #   | Risk                                       | Score | Band   | What We Are Doing                                 | Expected Closure |
| --- | ------------------------------------------ | ----- | ------ | ------------------------------------------------- | ---------------- |
| 1   | RISK-005: Credential stuffing on login API | 16    | High   | Rate limiting + MFA implementation in progress    | Jun 15 2027      |
| 2   | RISK-003: Over-privileged AWS IAM access   | 10    | Medium | Least-privilege IAM redesign; Eng Lead owns       | Jul 30 2027      |
| 3   | RISK-002: Laptop encryption gap            | 9     | Medium | MDM deployment 85% complete; 30 devices remaining | Jun 1 2027       |
 
# => Format rule: one row per risk, no jargon, concrete closure date
 
---
 
## PROGRAM HEALTH SNAPSHOT (KPIs)
 
# => Five numbers that summarize program health — link to Example 24 for detail
 
| KPI                               | Current | Last Quarter | Target  | Status                      |
| --------------------------------- | ------- | ------------ | ------- | --------------------------- |
| Phishing click rate               | 28%     | (baseline)   | < 5%    | Amber                       |
| Training completion               | 68%     | 0%           | 100%    | Amber                       |
| Critical vulns patched within SLA | N/A     | N/A          | 95%     | Grey (scanner not deployed) |
| Open Critical risks > 14 days     | 0       | 1            | 0       | Green                       |
| MTTD (mean time to detect)        | TBD     | N/A          | < 4 hrs | Grey (SIEM not deployed)    |
 
---
 
## BOARD ASKS
 
# => Be explicit — what do you need from the board today?
 
1. INFORMATION ONLY: Risk posture update (no action required)
2. APPROVAL: Q2 security roadmap initiatives — confirm budget allocation remains on track
3. AWARENESS: SOC 2 Type II decision point in Q3 — we will return with a recommendation

# AcmeSoft Security Exception Request Form
 
# Form ID: SEC-EXC-2027-004 | Classification: Confidential
 
## Section 1: Requestor Information
 
# => Identify who is accountable for this exception
 
Requestor name: Jamie Santos
Requestor title: VP Engineering
Department: Engineering
Date submitted: 2026-05-21
Approver(s) required: CISO (standard exceptions); CISO + CEO (exceptions > 90 days)
 
## Section 2: Policy Being Excepted
 
# => Name the specific policy and control — vague exceptions are unenforceable
 
Policy name: Access Control Policy v2.1
Control: Section 4.2 — MFA required for all internal systems containing Internal or higher data
Policy effective: 2027-01-01
Exception type: Technical infeasibility (legacy system does not support MFA)
 
## Section 3: Exception Scope
 
# => Describe exactly what is and is not covered
 
System affected: InternalWiki (Confluence Server 7.x, self-hosted)
Data classification: Internal
Users affected: All 200 AcmeSoft employees
Exception scope: MFA bypass for Confluence Server only — all other systems remain MFA-enforced
 
## Section 4: Business Justification
 
# => Why is exception necessary? What would happen if policy was enforced immediately?
 
Confluence Server 7.x does not support SAML/OIDC MFA integration.
Enforcing the policy would require migrating to Confluence Cloud or
Confluence Data Center (licensed differently). Migration requires
architectural planning and budget approval — not achievable by policy deadline.
Business impact of immediate enforcement: complete loss of internal wiki access for all staff.
 
## Section 5: Risk Assessment
 
# => Quantify the risk being accepted — this is the CISO's input, not requestor's
 
Likelihood of exploit during exception period: 2 (Unlikely)
 
# => Internal system; not internet-facing; attacker would need network access first
 
Impact if exploited: 3 (Moderate) — Internal-classified data; no customer PII
Risk score: 6 (Medium)
 
# => Exception is acceptable at this score; would require escalation if High/Critical
 
Compensating controls during exception period:
 
- IP allowlist: Confluence accessible only from AcmeSoft office IPs and VPN
  # => This compensates for missing MFA by restricting access to trusted networks
- Audit logging: all login events to Confluence monitored in SIEM
- Quarterly access review: user access list reviewed and certified by IT Manager
 
## Section 6: Remediation Plan
 
# => Every exception must have a path to compliance — open-ended exceptions are not permitted
 
Remediation: Migrate to Confluence Cloud with Atlassian Access (supports OIDC MFA)
Target compliance date: 2027-08-31
Remediation owner: VP Engineering
Budget required: $12,000/year (Confluence Cloud + Atlassian Access license)
Budget status: In FY2027 IT budget
 
## Section 7: Exception Duration
 
Requested exception period: 2027-01-01 to 2027-08-31 (8 months)
Maximum allowed without CEO approval: 90 days
 
# => This exception requires both CISO + CEO approval (> 90 days)
 
## Section 8: Approvals
 
CISO approval: **\*\*\*\***\_\_**\*\*\*\*** Date: \***\*\_\_\*\***
CEO approval: **\*\*\*\***\_\_**\*\*\*\*** Date: \***\*\_\_\*\***
Next review date: 2027-04-01 (mid-point check on remediation progress)

# AcmeSoft Internal Incident Notification
 
# Template: TMPL-INC-NOTIFY-INTERNAL | Version: 1.1
 
# Classification: CONFIDENTIAL — do not forward outside named recipients
 
---
 
TO: [CEO], [CTO], [CFO], [General Counsel], [VP Engineering], [Head of Support]
CC: [Incident Response Team members]
FROM: CISO
DATE: 2026-05-21 08:47 WIB
SUBJECT: [SECURITY INCIDENT — P2] Suspicious Database Access Detected — 2026-05-21
 
---
 
## SITUATION SUMMARY (3 sentences max)
 
# => Write this first — if you cannot summarize in 3 sentences, you do not yet understand the incident
 
At 08:15 WIB, our SIEM (Datadog Security) detected anomalous query patterns
on the production customer database originating from an IP address not associated
with any known AcmeSoft system or developer. No confirmed data exfiltration at
this time. The Incident Response Team is actively investigating.
 
## CURRENT SEVERITY
 
Severity: P2 — Contained compromise; potential data at risk
 
# => Use the severity definitions from Example 11 — consistent language matters
 
# => P2 means: we have contained or partially contained the incident; full impact unknown
 
## WHAT HAS BEEN DONE SO FAR
 
# => Report actions taken, not actions planned — keep plans in the response log
 
08:15 — Anomalous queries detected by SIEM alert
08:22 — CISO and Infra Lead paged; IRT assembled on Slack #incident-active
08:31 — Source IP blocked at AWS security group level (network isolation)
08:35 — Affected DB user credentials rotated
08:40 — Evidence preservation: RDS logs exported to secure S3 bucket
08:47 — This notification sent
 
# => Timestamped log is your audit trail — document as you act
 
## WHAT WE DO NOT YET KNOW
 
# => Explicitly stating unknowns prevents speculation and false rumor
 
- Whether any data was exfiltrated (forensic review in progress; ETA 2 hours)
- How the attacker obtained the DB credentials (investigation in progress)
- Whether other systems are affected (lateral movement check underway)
 
## POTENTIAL BUSINESS IMPACT
 
# => Give decision-makers the information they need to assess priority
 
If data exfiltration is confirmed:
 
- GDPR Art. 33: 72-hour supervisory authority notification required
  # => Tag the clock for Legal — they need to know this NOW
- GDPR Art. 34: Customer notification may be required if high risk to rights
- Potential PII affected: up to [X] customer records (investigation will determine)
 
## IMMEDIATE ACTIONS REQUIRED FROM THIS GROUP
 
# => Do not ask for general "awareness" — give specific asks
 
| Recipient       | Action Required                                                             | By                   |
| --------------- | --------------------------------------------------------------------------- | -------------------- |
| General Counsel | Stand by for GDPR 72-hr notification decision (legal review by 11:00)       | 11:00 WIB            |
| CFO             | Locate cyber insurance policy; confirm breach response coverage             | 10:00 WIB            |
| Head of Support | Do NOT respond to customer inquiries about the system until cleared by CISO | Until further notice |
| All others      | Information only — no action required at this time                          | —                    |
 
## NEXT UPDATE
 
# => Always commit to a specific update time — prevents inbox flooding with "any update?"
 
Next update: 2026-05-21 11:00 WIB or sooner if material development occurs
Incident channel: #incident-20260521-db-anomaly (Slack)
Incident commander: [CISO name], mobile: [number]

# AcmeSoft Security Culture Assessment
 
# Methodology: Self-report survey + behavioral observation
 
# Owner: CISO | Cadence: Annual | Sample: All 200 employees | Date: 2026-05-21
 
## Survey Instructions
 
# => Anonymous survey — emphasize anonymity to get honest responses
 
Rate each statement on a scale of 1–5:
1 = Strongly Disagree 2 = Disagree 3 = Neutral 4 = Agree 5 = Strongly Agree
 
---
 
## Dimension 1: Leadership Commitment
 
# => Culture flows from the top — this dimension predicts all others
 
Q1. Senior leaders visibly demonstrate that security is a business priority.
Q2. When security and productivity conflict, leadership supports the secure option.
Q3. I have heard the CEO or executive team discuss security in the past 3 months.
Q4. Security investment requests from the CISO are treated seriously by leadership.
Max dimension score: 20
 
## Dimension 2: Employee Knowledge and Awareness
 
# => Can employees identify threats and know what to do?
 
Q5. I know how to identify a phishing email.
Q6. I know where to report a suspicious email or security concern.
Q7. I understand our data classification scheme and what each label means.
Q8. I have completed all required security training modules this year.
Q9. I feel confident I could recognize a social engineering attempt.
Max dimension score: 25
 
## Dimension 3: Security Behaviors (Day-to-Day)
 
# => Measuring intended behaviors — not perfect, but directional
 
Q10. I always lock my screen when stepping away from my desk.
Q11. I use a password manager for all work accounts.
Q12. I have never shared my work password with a colleague.
Q13. I report security concerns even when I am unsure if they are serious.
Q14. I avoid clicking links in unsolicited emails even when they look legitimate.
Max dimension score: 25
 
## Dimension 4: Psychological Safety for Security Reporting
 
# => Fear of blame suppresses incident and near-miss reporting
 
Q15. I feel comfortable reporting a security mistake I made without fear of punishment.
Q16. If I accidentally clicked a phishing link, I would report it immediately.
Q17. Security policies are explained to me with rationale, not just mandated.
Q18. When I raised a security concern in the past, it was taken seriously.
Max dimension score: 20
 
## Dimension 5: Process Integration
 
# => Is security embedded in how work gets done, or bolted on?
 
Q19. Security considerations are part of how my team plans new projects.
Q20. I have the tools I need to work securely without creating workarounds.
Q21. Security processes are designed to be workable, not just secure.
Q22. I know who to escalate a security decision to when I am unsure.
Max dimension score: 20
 
---
 
## Scoring Rubric
 
| Dimension Score (% of max) | Maturity Level | Interpretation                                        |
| -------------------------- | -------------- | ----------------------------------------------------- |
| 85–100%                    | Optimizing     | Security culture is a genuine organizational strength |
| 70–84%                     | Managed        | Solid foundations; targeted improvements needed       |
| 55–69%                     | Defined        | Awareness exists; behavior gaps remain                |
| 40–54%                     | Developing     | Compliance focus; culture work needed                 |
| < 40%                      | Initial        | Foundational culture investment required              |
 
Overall Score = (Total score / 110) × 100
 
# => Max total: 110 points across all 22 questions
 
---
 
## Interpreting Results: Action Matrix
 
| Dimension               | Score < 55% | Priority Action                                                         |
| ----------------------- | ----------- | ----------------------------------------------------------------------- |
| Leadership Commitment   | < 55%       | Executive security champion program; CEO security keynote at all-hands  |
| Knowledge and Awareness | < 55%       | Redesign training program; increase frequency; role-based modules       |
| Security Behaviors      | < 55%       | Phishing simulation campaign (Example 10); behavioral nudges in tooling |
| Psychological Safety    | < 55%       | No-blame incident culture campaign; public recognition for reporters    |
| Process Integration     | < 55%       | Security champions program in each team; embed security in SDLC         |
 
---
 
## AcmeSoft Baseline Results (Q1 2027)
 
| Dimension               | Score / Max  | Percentage | Maturity    |
| ----------------------- | ------------ | ---------- | ----------- |
| Leadership Commitment   | 13 / 20      | 65%        | Defined     |
| Knowledge and Awareness | 14 / 25      | 56%        | Defined     |
| Security Behaviors      | 16 / 25      | 64%        | Defined     |
| Psychological Safety    | 10 / 20      | 50%        | Developing  |
| Process Integration     | 11 / 20      | 55%        | Defined     |
| **OVERALL**             | **64 / 110** | **58%**    | **Defined** |
 
Priority focus areas for FY2027:
 
1. Psychological Safety (50% — Developing) — launch no-blame reporting culture program
2. Knowledge and Awareness (56% — barely Defined) — redesign training with role-based modules
3. Leadership Commitment (65%) — brief CEO; add security to quarterly all-hands agenda
 
# => Security behaviors (64%) and process integration (55%) are secondary priorities