Beginner

# AcmeSoft IT Governance Decision Rights Framework v1.0
 
governance_body: Board IT Committee
# => Board-level body — sets the outer boundary of IT authority
 
decisions_reserved_to_board:
  - approve_it_strategy: true
  # => Strategy approval cannot be delegated below board level
  - set_risk_appetite: true
  # => Risk appetite is a governance decision — defines what losses are acceptable
  - approve_major_investments:
      threshold_usd: 500000
      # => Investments above $500K require board sign-off; below this, CIO decides
  - oversee_compliance_posture: true
  # => Board is accountable to regulators and shareholders for compliance
 
decisions_delegated_to_management:
  - it_project_execution: CIO
  # => Once approved, execution authority belongs to management
  - vendor_selection_below_threshold: IT_Director
  # => Routine procurement does not require board involvement
  - incident_response: CISO
  # => Operational decisions during incidents must be fast — not committee-driven
 
review_cadence: quarterly
# => Governance bodies that meet less than quarterly lose situational awareness

# Nexatech COBIT Governance vs Management Boundary
 
governance_domain:
  name: EDM
  # => EDM = Evaluate, Direct, Monitor — the only COBIT governance domain
  responsible_body: Board IT Committee
  # => Board-level accountability; cannot be fully delegated to management
  objectives:
    - EDM01_Ensured_Governance_Framework_Setting:
        what: Establish and maintain governance framework
        # => Sets the rules of the game; everything else operates within this frame
    - EDM02_Ensured_Benefits_Delivery:
        what: Oversee value delivery from IT investments
        # => Board asks "did we get the return we expected?" not "how was it built?"
    - EDM03_Ensured_Risk_Optimization:
        what: Ensure IT risks are identified and managed within appetite
        # => Risk appetite is set here; treatment decisions live in management domain
    - EDM04_Ensured_Resource_Optimization:
        what: Ensure adequate IT resources are available
        # => Headcount and budget envelope — strategic, not operational
    - EDM05_Ensured_Stakeholder_Engagement:
        what: Ensure stakeholder communication and reporting
        # => Board ensures stakeholders (investors, regulators) receive timely information
 
management_domains:
  APO:
    name: Align, Plan, Organize
    # => APO translates governance direction into IT plans and structures
    responsible_body: CIO and IT leadership
    example_objective: APO02 — Managed Strategy
    # => CIO owns the IT strategy document; Board only approves or rejects it
 
  BAI:
    name: Build, Acquire, Implement
    # => BAI covers how IT solutions are created or procured
    responsible_body: IT Director, Project Managers
    example_objective: BAI01 — Managed Programs
    # => Day-to-day project execution is pure management — governance reviews outcomes
 
  DSS:
    name: Deliver, Service, Support
    # => DSS covers operational IT service delivery
    responsible_body: IT Operations, Service Desk
    example_objective: DSS02 — Managed Service Requests and Incidents
    # => Incident response is a management activity; governance reviews incident trends
 
  MEA:
    name: Monitor, Evaluate, Assess
    # => MEA closes the feedback loop — management monitors, governance uses results
    responsible_body: IT Audit, Risk Manager
    example_objective: MEA01 — Managed Performance and Conformance Monitoring
    # => MEA feeds KPIs and audit findings upward to governance bodies

# AcmeSoft COBIT 2019 Governance Principles — Practitioner Summary
 
principles:
  1_provide_stakeholder_value:
    statement: IT governance exists to create value for stakeholders
    # => Value is the ultimate test of any governance decision — not compliance or process
    practical_meaning: Every IT investment must trace back to a stakeholder benefit
    # => At AcmeSoft: customer uptime, developer productivity, investor confidence
    common_mistake: Treating governance as a compliance checkbox rather than a value driver
 
  2_holistic_approach:
    statement: Governance requires considering all components together
    # => People, processes, information, technology, culture — all interact
    practical_meaning: Fixing a process without addressing the culture that bypasses it fails
    # => AcmeSoft: implementing change management software without training → shelfware
    components: [principles_policies, processes, org_structures, culture, information, services, people, infrastructure]
 
  3_dynamic_governance_system:
    statement: Governance must adapt as the enterprise and environment change
    # => A static governance framework becomes irrelevant as the business scales
    practical_meaning: Review governance objectives annually — not just at initial setup
    # => AcmeSoft: governance at 50 people differs from governance at 500 people
    trigger_for_review: [new_regulation, M&A, major_technology_shift, significant_incident]
 
  4_governance_distinct_from_management:
    statement: Governance (Board/C-suite) is separate from management (CIO/IT)
    # => This is the EDM vs APO/BAI/DSS/MEA split from Example 2
    practical_meaning: Board sets direction and monitors; IT management executes
    # => Prevents both micromanagement and accountability gaps
 
  5_tailored_to_enterprise_needs:
    statement: COBIT must be adapted to the specific enterprise context
    # => A 200-person SaaS does not implement all 40 COBIT objectives equally
    practical_meaning: Select and scope governance objectives based on risk profile
    # => AcmeSoft priority: EDM03 (risk), APO07 (people), DSS05 (security)
    design_factors: [enterprise_size, risk_profile, regulatory_environment, IT_strategy]
 
  6_end_to_end_governance_system:
    statement: Governance covers the entire enterprise, not just the IT department
    # => IT governance extends to business units that use and own IT assets
    practical_meaning: Business unit heads share accountability for IT outcomes
    # => AcmeSoft: Marketing VP owns data governance for CRM; not just IT's job
    scope: [internal_IT, outsourced_services, shadow_IT, cloud_services]

# Meridian Health COBIT 2019 Domain Map
 
domains:
  EDM:
    full_name: Evaluate, Direct, Monitor
    type: GOVERNANCE
    # => Only governance domain — board-level accountability
    objective_count: 5
    # => EDM01–EDM05; fewer objectives because governance sets direction, not detail
    owner: Board IT Committee
    # => Board cannot delegate governance accountability, only management execution
    example_objective:
      id: EDM03
      name: Ensured Risk Optimization
      # => Board ensures IT risks are identified, assessed, and managed within appetite
      what_it_does: Sets risk appetite and ensures risk management is operating
      meridian_health_application: HIPAA breach risk must stay within board-defined tolerance
 
  APO:
    full_name: Align, Plan, Organize
    type: MANAGEMENT
    # => Translates governance direction into actionable IT plans
    objective_count: 14
    # => Largest domain — planning is complex and touches many areas
    owner: CIO
    example_objective:
      id: APO12
      name: Managed Risk
      # => Management-level risk process — operationalizes EDM03's risk appetite
      what_it_does: Identifies, analyses, and responds to IT risks continuously
      meridian_health_application: Quarterly risk assessment of EHR system vulnerabilities
 
  BAI:
    full_name: Build, Acquire, Implement
    type: MANAGEMENT
    # => Covers how IT solutions are developed or procured
    objective_count: 11
    owner: IT Director / Project Management Office
    example_objective:
      id: BAI06
      name: Managed IT Changes
      # => Formal change management — prevents unauthorized changes breaking production
      what_it_does: Ensures all IT changes are evaluated, authorized, prioritized, and tracked
      meridian_health_application: EHR software updates require CAB approval before deployment
 
  DSS:
    full_name: Deliver, Service, Support
    type: MANAGEMENT
    # => Day-to-day IT operations — what end users experience
    objective_count: 6
    owner: IT Operations Manager
    example_objective:
      id: DSS05
      name: Managed Security Services
      # => Operational security — firewall rules, AV, patch application
      what_it_does: Protects IT systems and information from security threats
      meridian_health_application: 24/7 monitoring of network access to PHI systems
 
  MEA:
    full_name: Monitor, Evaluate, Assess
    type: MANAGEMENT
    # => Closes the feedback loop — measures whether governance objectives are being met
    objective_count: 4
    owner: IT Audit / Risk Manager
    example_objective:
      id: MEA01
      name: Managed Performance and Conformance Monitoring
      # => Measures actual IT performance against targets — feeds board reporting
      what_it_does: Collects and reports on IT performance and compliance metrics
      meridian_health_application: Monthly dashboard to Board IT Committee on HIPAA control status
 
total_objectives: 40
# => 5 (EDM) + 14 (APO) + 11 (BAI) + 6 (DSS) + 4 (MEA) = 40

# Nexatech ISO/IEC 38500:2024 Principles — Board Reference Card
 
standard: ISO/IEC 38500:2024
edition: Third (February 2024)
# => Current version — supersedes 2015 edition; confirms six-principle structure
audience: Governing body (Board of Directors, Executive Committee)
# => Standard addresses directors, not IT managers — governance not operations
 
principles:
  responsibility:
    number: 1
    statement: Individuals and groups understand and accept their IT responsibilities
    # => No accountability without clear ownership — ambiguity enables blame-shifting
    board_obligation: Ensure IT responsibility is assigned, understood, and accepted
    nexatech_action: IT RACI matrix published and acknowledged by all named owners
    # => Annual sign-off on IT responsibilities is sufficient evidence of compliance
 
  strategy:
    number: 2
    statement: IT strategy aligns with and supports the business strategy
    # => IT investment priorities must trace back to business goals, not IT preferences
    board_obligation: Review IT strategy alignment at least annually
    nexatech_action: CIO presents IT strategy alignment report to board each April
    # => Boards that skip this check often find IT optimizing for the wrong outcomes
 
  acquisition:
    number: 3
    statement: IT acquisitions are made for valid reasons with appropriate analysis
    # => Prevents technology-for-technology's-sake purchases
    board_obligation: Approve acquisition policy and oversee major IT procurement decisions
    nexatech_action: Business case required for all IT acquisitions above $50K
    # => Threshold should reflect organizational scale — too low creates bureaucracy
 
  performance:
    number: 4
    statement: IT delivers the services needed to meet current and future business needs
    # => Governance must ensure IT performance is measured and reported
    board_obligation: Receive regular IT performance reporting; set service expectations
    nexatech_action: Quarterly SLA dashboard presented to Executive Steering Committee
    # => Performance without measurement is guesswork — metrics make it governable
 
  conformance:
    number: 5
    statement: IT complies with mandatory legislation and regulations
    # => Non-conformance exposes the organization (and directors personally) to liability
    board_obligation: Ensure compliance obligations are identified and met
    nexatech_action: Annual compliance calendar reviewed by board; GDPR + PCI DSS tracked
    # => Directors can be personally liable for compliance failures in many jurisdictions
 
  human_behaviour:
    number: 6
    statement: IT policies and decisions respect human behaviour and human needs
    # => Technology that ignores human factors gets bypassed — creating security gaps
    board_obligation: Ensure IT policies consider impact on people, culture, and behaviour
    nexatech_action: Usability review for all new IT policies before publication
    # => Example: MFA policy that is too burdensome gets disabled or circumvented

# AcmeSoft IT Risk Management Process — ISO 31000:2018 Aligned
 
standard: ISO 31000:2018
scope: IT risk management (subset of enterprise risk)
# => ISO 31000 covers all risk types — this instance scopes to IT; same lifecycle applies
 
lifecycle:
  step_1_scope_context_criteria:
    iso_term: Establishing scope, context, and criteria
    # => Define the boundaries before identifying risks — avoids infinite scope
    what_to_do:
      - Define which IT systems, processes, and assets are in scope
      - Identify internal context (strategy, capabilities, culture)
      - Identify external context (regulations, market, technology threats)
      - Set risk evaluation criteria (what makes a risk High vs Low)
    acmesoft_output: IT Risk Management Policy with risk appetite statement
    # => Risk appetite must be documented before assessment — otherwise "High" is subjective
 
  step_2_risk_assessment:
    iso_term: Risk assessment (identification + analysis + evaluation)
    # => Three sub-steps bundled in ISO 31000 as one assessment step
    substeps:
      identification:
        method: [workshops, threat intelligence, asset register review]
        # => Multiple identification methods catch risks a single method misses
        output: Risk register with assets, threats, and vulnerabilities listed
      analysis:
        method: Likelihood × Impact scoring (see Example 14 for 5×5 matrix)
        # => Analysis converts identified risks into comparable scores
        output: Risk scores and risk heat map
      evaluation:
        method: Compare risk scores against risk appetite
        # => Evaluation decides which risks need treatment — not all risks require action
        output: Prioritized risk list with treatment decisions
 
  step_3_risk_treatment:
    iso_term: Risk treatment
    # => What the organization does about the risks it cannot accept
    options: [mitigate, accept, transfer, avoid]
    # => See Example 15 for full treatment option decision table
    output: Risk treatment plan with controls, owners, and due dates
    # => Treatment without an owner and due date is a wish, not a plan
 
  step_4_monitoring_and_review:
    iso_term: Monitoring and review
    # => Risk management without monitoring degrades into a one-time exercise
    frequency:
      risk_register_review: quarterly
      # => Quarterly minimum — new threats emerge continuously
      risk_appetite_review: annual
      # => Appetite can change as business strategy changes
      treatment_progress_review: monthly
      # => Owners need monthly check-ins to stay on track
    escalation: Risks that breach appetite thresholds escalate to IT Risk Committee
 
  step_5_recording_and_reporting:
    iso_term: Recording and reporting
    # => ISO 31000 requires documented evidence — critical for audits
    outputs:
      - Risk register (living document)
      - Risk treatment plan with status tracking
      - Board risk dashboard (summary for governance body)
      - Audit trail of risk decisions
    acmesoft_tool: Shared spreadsheet initially; risk management platform at scale
    # => Start simple — a well-maintained spreadsheet beats an unused GRC tool
 
  supporting_activities:
    communication_and_consultation:
      # => Risk owners must be engaged throughout — not just informed of results
      what: Involve risk owners in identification and treatment planning
    continual_improvement:
      # => Process itself must be reviewed for effectiveness, not just risks within it
      what: Annual review of the risk management process maturity

# Meridian Health ITIL 4 Service Value System — Orientation Reference
 
framework: ITIL 4
status: Established baseline (ITIL V5 launched Feb 12, 2026 — ITIL 4 remains predominant)
# => Organizations trained on ITIL 4 should not migrate to V5 without a deliberate plan
purpose: Describes how all components of an IT organization create value together
 
service_value_system_components:
  guiding_principles:
    count: 7
    # => Seven principles that inform all ITIL decisions — not prescriptive rules
    examples:
      - Focus on value
      # => Every IT activity must trace back to value for a stakeholder
      - Start where you are
      # => Assess existing capabilities before redesigning from scratch
      - Progress iteratively with feedback
      # => Incremental improvement beats big-bang transformation
      - Think and work holistically
      # => Services interact — optimizing one process can break another
      - Keep it simple and practical
      # => Governance overhead that exceeds benefit should be removed
    meridian_health_application: Help desk improvements follow "Start where you are" — audit current state first
 
  governance:
    role_in_svs: Directs and controls ITIL activities within organizational governance
    # => ITIL governance is the same board/management distinction as COBIT — consistent principle
    what_it_does: Evaluates, directs, and monitors IT service management activities
    relationship_to_cobit: ITIL governance aligns with COBIT EDM domain
    # => Organizations using both frameworks map ITIL governance to COBIT EDM objectives
 
  service_value_chain:
    activities: [Plan, Improve, Engage, Design_and_Transition, Obtain_and_Build, Deliver_and_Support]
    # => Six activities — flexible paths through the chain, not a fixed waterfall
    how_it_works: Activities combine to form value streams for specific services
    meridian_health_example:
      trigger: Clinician requests new EHR report feature
      path: Engage → Design_and_Transition → Obtain_and_Build → Deliver_and_Support
      # => Not every request follows the same path — value chain is adaptive
 
  practices:
    total_count: 34
    # => 14 general management + 17 service management + 3 technical management
    key_practices_for_beginners:
      - Incident Management
      # => Restore service quickly — separate from Problem Management (root cause)
      - Change Enablement
      # => Controls change risk — formerly "Change Management" in ITIL v3
      - Service Desk
      # => Single point of contact for users — channels all other practices
      - Problem Management
      # => Finds root causes of recurring incidents — reduces incident volume
    meridian_health_application: Service Desk + Incident Management are first two practices to mature
 
  continual_improvement:
    role_in_svs: Runs throughout all SVS components — not a separate phase
    # => Improvement is not a project to complete; it is a permanent operating mode
    model: Plan → Do → Check → Act (PDCA basis)
    meridian_health_action: Monthly service review meeting reviews improvement backlog
    # => Without a structured review cadence, improvement ideas die in inboxes

# Nexatech IT Governance Committee Structure
 
committees:
  board_it_committee:
    tier: 1_governance
    # => Tier 1 = governance body — sets direction, does not manage operations
    composition:
      - 2 independent board directors (one chairs)
      # => Independent directors prevent IT committee from rubber-stamping management proposals
      - CEO
      - CIO (non-voting advisor)
      # => CIO attends to provide context — voting reserved for board members
      - External IT governance advisor (optional)
    meeting_cadence: quarterly
    # => Quarterly minimum for governance — monthly is too operational for a board committee
    decides:
      - IT strategy approval
      - Major IT investment approval (above $500K)
      - IT risk appetite
      - IT governance framework selection (COBIT, ISO 38500)
    receives_reports_from: Executive Steering Committee
 
  executive_steering_committee:
    tier: 2_executive_management
    # => Tier 2 = senior management — bridges governance and operational management
    composition:
      - CEO (chairs)
      - CIO
      - CISO
      - CFO
      - Business unit heads (rotating seat)
      # => Business representation ensures IT serves business needs, not just IT preferences
    meeting_cadence: monthly
    decides:
      - IT program prioritization within approved strategy
      - Cross-functional IT resource allocation
      - Escalated risks that breach operational thresholds
    reports_to: Board IT Committee (quarterly summary)
 
  it_risk_committee:
    tier: 3_operational_management
    # => Tier 3 = operational management — manages risks within approved appetite
    composition:
      - CISO (chairs)
      - IT Risk Manager
      - IT Audit representative
      - Business risk owner representatives
      # => Business owners sit here because they own the assets being protected
    meeting_cadence: monthly
    decides:
      - Risk treatment approvals within appetite
      - Control exception approvals (time-limited)
      - Risk register updates and prioritization
    escalates_to: Executive Steering Committee (risks exceeding appetite)
 
  change_advisory_board:
    tier: 3_operational_management
    # => CAB is a parallel Tier 3 body — peer to IT Risk Committee, not subordinate
    composition:
      - IT Operations Manager (chairs)
      - System owners (affected by changes)
      - Security representative
      - Service Desk representative
      # => Service Desk knows what will break user workflows — essential voice
    meeting_cadence: weekly
    # => Weekly cadence matches typical change deployment cycle
    decides:
      - Change approval (normal and standard changes)
      - Emergency change post-implementation review
    escalates_to: Executive Steering Committee (changes with strategic impact)

# AcmeSoft RACI — Approve Major IT Investment (above $250K)
 
decision: Approve major IT investment
# => Threshold set at $250K — calibrate to org size; too low creates committee fatigue
 
roles:
  R: Responsible — performs the work to prepare the decision
  A: Accountable — one person; owns the outcome; cannot be shared
  # => RACI fails when Accountable is assigned to a committee — dilutes ownership
  C: Consulted — two-way input before decision; their input changes the decision
  I: Informed — one-way notification after decision; does not change it
  # => Distinguishing C from I prevents unnecessary stakeholders from slowing decisions
 
raci_matrix:
  # Format: Role | RACI Assignment | Rationale
 
  Board_IT_Committee:
    assignment: A
    # => Accountable = final approval authority; cannot be delegated for major investments
    rationale: Board is ultimately accountable to shareholders for capital allocation
 
  CEO:
    assignment: C
    # => Consulted = CEO input shapes the business case; board makes final call
    rationale: CEO confirms strategic alignment before board vote
 
  CIO:
    assignment: R
    # => Responsible = CIO prepares the business case and technical justification
    rationale: CIO owns the IT strategy and delivers the investment recommendation
 
  CFO:
    assignment: C
    # => Consulted = CFO validates financial projections and funding source
    rationale: Financial credibility of the business case requires CFO validation
 
  CISO:
    assignment: C
    # => Consulted = CISO reviews security and risk implications of the investment
    rationale: Major IT investments may introduce new attack surface or compliance obligations
 
  IT_Director:
    assignment: R
    # => Responsible (joint with CIO) = IT Director supports business case preparation
    rationale: Operational feasibility assessment requires IT Director's delivery expertise
 
  Business_Unit_Head:
    assignment: C
    # => Consulted = BU head confirms the investment addresses a real business need
    rationale: Investments without business sponsor rarely deliver expected value
 
  Legal_Counsel:
    assignment: C
    # => Consulted for contracts, data privacy, or regulatory implications
    rationale: Major investments often involve vendor contracts requiring legal review
 
  IT_Risk_Committee:
    assignment: I
    # => Informed = risk committee tracks approved investments for risk monitoring
    rationale: Risk committee adds investment to risk register after approval
 
  Project_Management_Office:
    assignment: I
    # => Informed = PMO adds approved project to portfolio tracking
    rationale: PMO needs approval notification to initiate project onboarding

# Meridian Health IT Policy Hierarchy
 
hierarchy:
  tier_1_policy:
    definition: High-level statement of intent, management commitment, and guiding principles
    # => Policy states WHAT the organization requires and WHY — not HOW to do it
    approved_by: Board of Directors or CEO
    # => Top-tier documents require top-tier approval to have governing authority
    review_cycle: Annual
    # => Policies change less frequently than procedures — stability is the goal
    example: Information Security Policy
    # => "Meridian Health protects PHI in accordance with HIPAA and ISO 27001"
    characteristics:
      - Technology-agnostic
      # => Policy must survive technology changes — do not name specific vendors
      - Brief (1–3 pages)
      - Mandatory compliance — no discretion allowed
    owned_by: CISO (for security policies), CIO (for IT policies)
 
  tier_2_standard:
    definition: Mandatory technical or process requirements that implement the policy
    # => Standards state WHAT specifically is required — measurable and auditable
    approved_by: CIO or CISO
    # => Management-level approval; does not require board sign-off
    review_cycle: Annual or when technology changes
    example: Password Standard
    # => "Passwords must be minimum 14 characters, include complexity, expire every 90 days"
    characteristics:
      - Specific and measurable
      # => "Strong passwords required" is policy language; "14 characters minimum" is standard
      - Technology may be named (e.g., specific algorithm requirements)
      - Mandatory compliance — no discretion
    owned_by: IT Security Manager, System Owners
 
  tier_3_procedure:
    definition: Step-by-step instructions for performing a specific task
    # => Procedures state HOW — detailed enough that a trained employee can follow them
    approved_by: IT Manager or Department Head
    # => Operational-level approval — procedures change more frequently than policies
    review_cycle: Semi-annual or when process changes
    example: New Employee Account Provisioning Procedure
    # => Step 1: HR submits access request form... Step 2: IT verifies role... etc.
    characteristics:
      - Task-specific, numbered steps
      # => Numbered steps enable auditors to verify each step was performed
      - Names specific systems and tools
      - May differ by department or system
    owned_by: Process Owner (e.g., IT Operations Manager for provisioning)
 
  tier_4_guideline:
    definition: Recommended (non-mandatory) best practices and advice
    # => Guidelines state what is advised — users may deviate with documented rationale
    approved_by: Technical Lead or Working Group
    # => Lower approval threshold reflects non-mandatory nature
    review_cycle: As needed
    example: Secure Coding Guideline
    # => "We recommend input validation at every API boundary" — not mandated
    characteristics:
      - Advisory, not mandatory
      # => If it is mandatory, it should be a standard or procedure — not a guideline
      - Provides flexibility for context-dependent decisions
      - Supports policy compliance but does not enforce it
    owned_by: Technical community, working groups
 
hierarchy_rules:
  - Lower tiers cannot contradict higher tiers
  # => Procedure cannot permit what the policy prohibits
  - Each document must reference its parent tier
  # => Procedure cites the Standard it implements; Standard cites the Policy
  - Gaps create risk — if no standard exists for a policy statement, write one

# AcmeSoft Acceptable Use Policy
 
# Version: 1.3 | Owner: CIO | Approved by: CEO | Review cycle: Annual
 
# Classification: Internal | Effective: 2026-05-21
 
## 1. Purpose
 
<!-- => Purpose section answers WHY — auditors and employees read this first -->
 
This policy defines acceptable use of AcmeSoft information technology
systems to protect company assets, maintain regulatory compliance, and
ensure business continuity.
 
## 2. Scope
 
<!-- => Scope must be explicit — ambiguity creates unenforceable policy -->
 
Applies to: All employees, contractors, consultants, and third-party
vendors with access to AcmeSoft systems.
Covers: All AcmeSoft-owned or managed systems, networks, devices,
applications, and data — regardless of physical location.
 
<!-- => "Regardless of physical location" captures remote and home office use -->
 
## 3. Definitions
 
<!-- => Define key terms to prevent "I interpreted it differently" defenses -->
 
- Company Systems: Any hardware, software, network, or cloud service
  owned, leased, or managed by AcmeSoft.
- Acceptable Personal Use: Incidental personal use that does not
  interfere with job duties or company resources.
 
## 4. Acceptable Use
 
<!-- => State permitted behaviors explicitly — reduces ambiguity about what IS allowed -->
 
- Use company systems primarily for authorized business purposes.
- Limited personal use is permitted when it does not affect productivity
  or system performance.
- Access only systems and data required for your assigned role.
 
<!-- => Least-privilege principle embedded in behavioral policy -->
 
## 5. Prohibited Use
 
<!-- => Explicit prohibitions provide the basis for disciplinary action -->
 
- Sharing login credentials with any other person, including colleagues.
 
<!-- => #1 cause of insider-threat incidents — must be explicitly named -->
 
- Installing unauthorized software on company-owned devices.
- Storing, transmitting, or accessing illegal content.
- Using company resources for personal financial gain (crypto mining,
  freelance work, etc.).
 
<!-- => Explicit examples prevent "I didn't know that counted" responses -->
 
- Circumventing security controls (VPN bypass, MFA removal, DLP tools).
- Accessing systems or data beyond your authorized role scope.
 
## 6. Monitoring and Privacy
 
<!-- => Legal requirement in most jurisdictions to disclose monitoring -->
 
AcmeSoft reserves the right to monitor company systems for security,
compliance, and business continuity purposes. Users have no expectation
of privacy on company-owned systems or networks.
 
## 7. Enforcement
 
<!-- => Clear consequence ladder ensures consistent application -->
 
Violations are subject to: written warning → suspension → termination
→ legal referral. Severity is determined by: data classification of
the affected asset + intent (accidental vs deliberate).
 
<!-- => Graduated response prevents overreaction to minor violations -->
 
## 8. Review Cycle
 
<!-- => Annual review keeps policy current with threat landscape changes -->
 
This policy is reviewed annually or following a significant security
incident. Next review: 2027-05-21.
 
## 9. Acknowledgement
 
<!-- => Signed acknowledgement is required for enforcement and audit evidence -->
 
By signing below, I confirm I have read, understood, and agree to
comply with this Acceptable Use Policy.
 
Name (print): \***\*\*\*\*\*\*\***\_\***\*\*\*\*\*\*\*** Date: **\*\***\_\_**\*\***
Signature: \***\*\*\*\*\*\*\***\_\_\_\***\*\*\*\*\*\*\*** Employee ID: **\_\_\_\_**

# Nexatech Information Asset Classification Policy — Annotation Layer
 
classification_rules:
  labeling_at_creation:
    rule: Every new data asset must be assigned a classification label at creation
    # => If labeling is deferred, it never happens — create before store
    default_when_uncertain: Confidential
    # => Erring toward Confidential costs some friction; erring toward Public costs a breach
 
  label_propagation:
    rule: Labels travel with the data across systems and formats
    # => A Restricted database export is still Restricted as a CSV on a laptop
    examples:
      - Email containing Restricted data → email subject line must indicate classification
      - Report generated from Confidential data → report inherits Confidential label
 
  downgrade_process:
    requires: [data_owner_approval, security_team_approval]
    # => Two-party approval prevents unauthorized downgrading to bypass controls
    documentation: Downgrade request form with business justification
    prohibited: Reclassifying Restricted → Public in a single step
    # => Stepwise downgrade (Restricted → Confidential → Internal → Public) is required
 
  third_party_sharing:
    confidential: Requires signed NDA + data sharing agreement
    restricted: Requires CISO approval + DPA + data transfer impact assessment
    # => Restricted data sharing with third parties is a board-reportable event
 
  annual_review:
    applies_to: All Restricted assets
    # => Restricted classification can accumulate — annual review prevents over-restriction
    reviewer: Data owner with IT Risk Manager validation
 
examples_by_classification:
  Public: [marketing_website, job_postings, published_API_docs]
  Internal: [meeting_notes, project_wikis, org_charts]
  Confidential: [customer_PII, source_code, financial_forecasts, contracts]
  Restricted: [PCI_card_data, biometric_data, M&A_plans, HR_disciplinary_records]

# AcmeSoft IT Risk Register v1.0 — Starter Set
 
register_metadata:
  owner: IT Risk Manager
  review_cycle: quarterly
  # => Quarterly review is the minimum to keep the register current
  status: Active
  last_updated: 2026-05-21
 
risks:
  RISK-001:
    asset: Customer PII database (PostgreSQL, AWS RDS)
    # => Specific asset name prevents ambiguity — "the database" is not auditable
    threat: Unauthorized access by external attacker
    # => Threat = the actor or event that could cause harm
    vulnerability: Overly permissive database security group rules (port 5432 open to 0.0.0.0/0)
    # => Vulnerability = the weakness that the threat exploits
    existing_controls:
      - Database password authentication
      # => Weak control — password-only auth is insufficient for a Restricted asset
      - AWS CloudTrail logging enabled
    risk_owner: IT Security Manager
    # => One named owner — committees do not own risks
    current_risk_level: High
    # => Level based on likelihood × impact (see Example 14 for scoring)
    target_risk_level: Low
    treatment_status: In Progress
 
  RISK-002:
    asset: Production deployment pipeline (GitHub Actions + AWS)
    threat: Supply chain attack via compromised third-party GitHub Action
    vulnerability: Third-party Actions used without pinning to specific commit SHA
    # => SHA pinning prevents an attacker who compromises a tag from injecting code
    existing_controls:
      - Dependabot alerts enabled
      - Manual code review for Action changes
    risk_owner: DevOps Lead
    current_risk_level: Medium
    target_risk_level: Low
    treatment_status: Not Started
 
  RISK-003:
    asset: Employee laptops (macOS, Windows — 200 devices)
    threat: Ransomware infection via phishing email
    vulnerability: No endpoint detection and response (EDR) tool deployed
    existing_controls:
      - macOS Gatekeeper and Windows Defender (default)
      - Annual phishing simulation
    risk_owner: IT Director
    current_risk_level: High
    target_risk_level: Medium
    treatment_status: In Progress
 
  RISK-004:
    asset: AWS production environment (all services)
    threat: Accidental data deletion by engineer with excessive IAM permissions
    vulnerability: Multiple engineers have AdministratorAccess IAM policy attached
    # => AdministratorAccess is rarely needed for day-to-day operations
    existing_controls:
      - AWS Config rules enabled
      - S3 versioning enabled for critical buckets
    risk_owner: CTO
    # => CTO owns this because it affects the entire production environment
    current_risk_level: High
    target_risk_level: Low
    treatment_status: Not Started
 
  RISK-005:
    asset: SaaS vendor integrations (Stripe, Salesforce, Okta — 12 vendors)
    threat: Vendor service outage causing AcmeSoft service disruption
    vulnerability: No formal vendor availability SLA review process; no fallback plan for critical vendors
    existing_controls:
      - Vendor uptime dashboards monitored ad hoc
    risk_owner: IT Director
    current_risk_level: Medium
    target_risk_level: Low
    treatment_status: Not Started

# Nexatech IT Risk Assessment — 5×5 Matrix
 
scoring_scale:
  likelihood:
    1: Rare (less than once in 5 years)
    2: Unlikely (once in 2–5 years)
    3: Possible (once per year)
    4: Likely (multiple times per year)
    5: Almost certain (monthly or more)
  impact:
    1: Negligible (no measurable business impact)
    2: Minor (limited impact, recovered quickly)
    3: Moderate (significant operational impact, recoverable)
    4: Major (significant financial or reputational loss)
    5: Critical (business-threatening; regulatory action; existential)
 
risk_appetite:
  statement: Nexatech accepts risks scoring 8 or below without treatment approval
  # => Appetite line at score 8 — risks above this require formal treatment plans
  approved_by: Board IT Committee
  # => Risk appetite must be board-approved — not set by IT management alone
  review_cycle: Annual
 
assessed_risks:
  # Format: Risk ID | Likelihood | Impact | Score | Zone | Exceeds Appetite?
 
  RISK-001:
    description: Unauthorized access to customer PII
    likelihood: 3
    # => Possible — misconfigured security group is known; exploitation is plausible
    impact: 5
    # => Critical — GDPR fine + customer churn + reputational damage
    score: 15
    # => 3 × 5 = 15; formula is always L × I
    zone: Critical
    exceeds_appetite: true
    treatment_required: Immediate
 
  RISK-002:
    description: Supply chain attack via GitHub Actions
    likelihood: 2
    # => Unlikely but demonstrated in real incidents (SolarWinds pattern)
    impact: 5
    # => Critical — production code injection could compromise all customer data
    score: 10
    zone: High
    exceeds_appetite: true
    treatment_required: Within 30 days
 
  RISK-003:
    description: Ransomware via phishing
    likelihood: 4
    # => Likely — phishing is the #1 delivery mechanism; no EDR means high success rate
    impact: 4
    # => Major — operational shutdown; ransom cost; recovery time
    score: 16
    zone: Critical
    exceeds_appetite: true
    treatment_required: Immediate
 
  RISK-004:
    description: Accidental data deletion by over-privileged engineer
    likelihood: 3
    # => Possible — human error with excessive permissions is a common incident type
    impact: 3
    # => Moderate — S3 versioning provides partial recovery; some data loss likely
    score: 9
    zone: High
    exceeds_appetite: true
    treatment_required: Within 60 days
 
  RISK-005:
    description: Critical SaaS vendor outage
    likelihood: 3
    # => Possible — SaaS outages occur; Stripe/Okta have had incidents
    impact: 3
    # => Moderate — operational disruption; financial loss; recoverable
    score: 9
    zone: High
    exceeds_appetite: true
    treatment_required: Within 60 days
 
risk_matrix_zones:
  # Score → Zone → Board Reporting Requirement
  1-4: Low (monitor; no treatment required)
  5-8: Medium (monitor; treat if cost-effective)
  # => Appetite line sits at 8 — risks at 9+ require formal treatment plans
  9-15: High (treatment plan required; report to IT Risk Committee)
  16-25: Critical (immediate treatment required; escalate to Board IT Committee)

# AcmeSoft Risk Treatment Decision Table
 
treatment_options:
  mitigate:
    definition: Implement controls to reduce likelihood, impact, or both
    # => Most common treatment — directly reduces risk through countermeasures
    when_to_use:
      - Risk score exceeds appetite
      - Cost of control is less than expected loss (expected loss = likelihood × impact value)
      - Technical control exists and is proportionate
    worked_example:
      risk: RISK-001 — Unauthorized access to customer PII (score 15, Critical)
      treatment: Restrict database security group to application server IPs only; enable RDS IAM authentication
      # => Mitigation directly addresses the vulnerability (open security group)
      expected_residual_score: 6
      # => After control: likelihood drops from 3 → 2; impact unchanged at 5; 2×5=10... wait
      # => With MFA + IP restriction: likelihood drops to 2; impact unchanged; score = 10
      # => Additional control (encryption) brings score to low — document residual
      owner: IT Security Manager
      due_date: 2026-06-21
 
  accept:
    definition: Formally document that the risk is within appetite and will not be treated
    # => Acceptance is not negligence — it is a documented, reviewed decision
    when_to_use:
      - Risk score is within appetite (at AcmeSoft: score ≤ 8)
      - Cost of treatment exceeds expected benefit
      - Risk is inherent to the business model (cannot be avoided without stopping the business)
    worked_example:
      risk: Public API rate limiting misconfiguration (score 4, Low)
      treatment: Accept — score within appetite; cost of additional WAF rule exceeds expected abuse impact
      # => Documented acceptance is governance evidence; undocumented acceptance is negligence
      review_trigger: Re-assess if exploitation attempt observed in logs
      approver: IT Risk Manager
      # => Acceptance must be approved by a named person — not assumed
 
  transfer:
    definition: Shift financial impact of the risk to a third party
    # => Transfer does not eliminate the risk — it changes who bears the financial consequence
    when_to_use:
      - Risk score exceeds appetite but cannot be cost-effectively mitigated
      - Third-party (insurance, cloud provider SLA) offers better loss absorption
      - Residual risk after mitigation still warrants financial coverage
    worked_example:
      risk: RISK-005 — SaaS vendor outage (score 9, High)
      treatment: Obtain cyber insurance policy covering business interruption from vendor outage
      # => Insurance does not prevent the outage — it covers financial loss after it occurs
      cost: $18,000/year premium
      coverage: Up to $2M business interruption loss
      limitation: Insurance does not cover reputational damage or customer churn
      # => Transfer is a financial tool, not a technical control — residual non-financial risk remains
      owner: CFO + IT Risk Manager
 
  avoid:
    definition: Eliminate the activity or asset that creates the risk
    # => Most drastic option — only appropriate when risk cannot be brought within appetite
    when_to_use:
      - Risk cannot be mitigated to an acceptable level at any cost
      - Business activity creating the risk has low strategic value
      - Regulatory requirement prohibits the activity
    worked_example:
      risk: Storing customer raw card numbers in AcmeSoft database (score 25, Critical)
      treatment: Avoid — cease storing raw card data; integrate Stripe for all card tokenization
      # => PCI DSS scope reduction via avoidance is a legitimate and common strategy
      result: PCI DSS scope reduced from SAQ D to SAQ A — eliminates 200+ control requirements
      # => Avoidance here is also the most cost-effective option by a large margin
      owner: CTO + CFO (strategic decision)

# Meridian Health Risk Treatment Plan — RISK-003
 
plan_metadata:
  risk_id: RISK-003
  created_date: 2026-05-21
  approved_by: CISO
  # => Treatment plans above appetite must be approved before work begins
  status: In Progress
  board_reporting_required: true
  # => Critical risks (score ≥ 16) are reported to Board IT Committee
 
risk_description:
  asset: Employee endpoints — 300 devices (macOS + Windows)
  threat: Ransomware delivery via targeted phishing email
  vulnerability: No EDR tool deployed; antivirus limited to OS-default protection
  current_likelihood: 4
  current_impact: 4
  current_score: 16
  current_zone: Critical
  # => Score 16 = Critical; board-reportable; immediate treatment required
 
treatment_approach: Mitigate
# => Mitigation chosen over Transfer because EDR is available, cost-effective, and
# => directly reduces likelihood; insurance alone would not reduce attack frequency
 
controls_to_implement:
  control_1:
    name: Deploy CrowdStrike Falcon EDR across all endpoints
    # => EDR selected over AV because it detects behavioral indicators of ransomware
    # => before encryption begins — AV only catches known signatures
    type: Preventive + Detective
    owner: IT Security Manager
    due_date: 2026-06-15
    estimated_cost: 36000_usd_annual
    # => $120/device/year × 300 devices; cost justified by ransomware recovery cost estimate of $500K+
    likelihood_reduction: 4 → 2
    # => EDR with behavioral detection reduces successful ransomware execution significantly
 
  control_2:
    name: Monthly phishing simulation + immediate training for failures
    # => Simulation addresses the human vector — EDR addresses the technical vector
    # => Both required because phishing success depends on both human and technical factors
    type: Preventive (awareness)
    owner: IT Risk Manager
    due_date: 2026-06-01
    estimated_cost: 4800_usd_annual
    # => $16/employee/year for simulation platform
    likelihood_reduction: Marginal additional reduction on top of EDR
 
  control_3:
    name: Implement offline immutable backup (3-2-1 backup rule)
    # => Immutable backup is the recovery control — reduces impact even if ransomware succeeds
    # => 3-2-1: 3 copies, 2 different media, 1 offsite (air-gapped or immutable)
    type: Corrective
    owner: IT Operations Manager
    due_date: 2026-07-01
    estimated_cost: 12000_usd_annual
    impact_reduction: 4 → 2
    # => With verified backup, recovery replaces ransom payment as the response path
 
residual_risk:
  residual_likelihood: 2
  residual_impact: 2
  residual_score: 4
  # => 2 × 2 = 4; within appetite (≤ 8); treatment plan achieves target
  residual_zone: Low
  next_review_date: 2026-11-21
  # => Six-month review confirms controls are effective in practice
 
total_treatment_cost: 52800_usd_annual
expected_loss_without_treatment: 500000_usd_estimated
# => ROI: $500K avoided loss / $52.8K treatment cost = 9.5× return
# => This calculation supports budget approval and board communication

# AcmeSoft Control Objective — Privileged Access Management
 
control_objective:
  id: CO-PAM-001
  # => Unique ID enables tracing from risk → control objective → control → audit test
  statement: >
    Ensure privileged access to production systems is granted only to
    authorized individuals based on documented business justification,
    approved by the system owner, reviewed quarterly, and revoked
    immediately upon role change or departure.
  # => A well-formed control objective is: specific, measurable, and auditable
  # => "Ensure privileged access is managed" is too vague — cannot be tested
 
  rationale:
    risk_addressed: Unauthorized access to production data by over-privileged accounts
    # => Every control objective should trace back to a specific risk in the risk register
    related_risk_id: RISK-001
    compliance_mapping:
      - SOC_2_CC6.1: Logical access security software, infrastructure, and architectures
      - ISO_27001_A.9.2.3: Management of privileged access rights
      # => Mapping to frameworks shows auditors the objective is not invented — it is standard practice
 
  criteria:
    # => Criteria define WHAT must be true for the objective to be met — auditable conditions
    - Privileged access requests must be submitted via the ITSM ticketing system
    - Each request must include documented business justification
    - Approval from the system owner is required before access is granted
    - Privileged accounts are reviewed quarterly; unused accounts revoked within 5 business days
    - Termination triggers immediate revocation (same business day)
    # => Each criterion maps to a specific audit test (see Example 19)
 
  control_owner: IT Security Manager
  # => One named owner — the person who ensures the objective is met
 
  measurement:
    kpi: Percentage of privileged access reviews completed on schedule
    target: 100%
    # => Objective without measurement cannot confirm compliance
    measurement_frequency: Quarterly
    data_source: Identity Management System (Okta) access review report
 
  policy_reference: Access Control Policy v2.1, Section 4.3
  # => Must trace to a Tier 2 standard or Tier 1 policy (see Example 10)

# Nexatech Control Type Reference — Privileged Access Domain
 
preventive_controls:
  examples:
    - name: Multi-factor authentication on all privileged accounts
      how_it_works: Requires something-you-know + something-you-have before granting access
      # => Prevents unauthorized login even if password is stolen
      strength: High (raises attacker cost significantly)
      gap: Does not prevent misuse by a legitimate authenticated user
 
    - name: Just-in-time (JIT) privileged access via CyberArk
      how_it_works: Privileges are elevated only when requested, for a defined time window
      # => Eliminates standing privileged access — reduces exposure window to minutes
      strength: High (no standing privileges = no stealable standing tokens)
 
detective_controls:
  examples:
    - name: SIEM correlation rule — bulk data export by privileged user
      how_it_works: Fires alert when a user downloads more than 1,000 records in one session
      # => Detects potential data exfiltration in near real-time
      strength: Medium (reduces time-to-detect; does not prevent the export)
      gap: Attacker can bypass by exporting below threshold over multiple sessions
 
    - name: Quarterly access certification review in Okta
      how_it_works: System owners attest whether each privileged account is still required
      # => Detective at program level — identifies drift from approved access state
      # => Frequency matters: quarterly is minimum; monthly is better for high-risk systems
 
corrective_controls:
  examples:
    - name: Automated account lockout after 5 failed login attempts
      how_it_works: Account suspended for 30 minutes after threshold; reduces brute-force effectiveness
      # => Corrective because it responds to detected attack (failed logins)
      # => Also has preventive effect on ongoing brute-force attempt
      note: Corrective and preventive properties can coexist in one control
 
    - name: Privileged session recording with playback capability
      how_it_works: All privileged sessions recorded; replay enables forensic investigation
      # => Corrective — used after an incident to reconstruct what happened
      strength: High for forensics; no preventive value
 
compensating_controls:
  when_to_use: When the primary control cannot be implemented due to technical or business constraints
  # => Compensating controls are temporary — document the timeline to implement primary
  example:
    primary_control: Automated access review in identity management system
    reason_unavailable: New system migration — automated review not yet configured
    compensating_control: Manual spreadsheet access review by IT Security Manager
    # => Compensating controls must be documented, time-limited, and reviewed
    time_limit: Until automated review is operational (target: 2026-08-01)
    risk_acknowledgement: CISO formally accepts increased residual risk during compensating period

# AcmeSoft Control Test Plan — CO-PAM-001 Privileged Access Quarterly Review
 
control_under_test:
  id: CO-PAM-001
  description: Privileged access reviewed quarterly; unused accounts revoked within 5 business days
  control_type: Detective + Preventive
  # => This control detects access drift (detective) and prevents unauthorized standing access (preventive)
 
test_of_design:
  objective: Confirm the control, as designed, is capable of achieving CO-PAM-001's stated objective
  # => ToD tests the control on paper — does the design make sense?
  procedures:
    - procedure: Obtain and review the Access Control Policy and access review procedure
      evidence_type: Inspection
      # => Inspection = examining documents; no people required
      what_to_look_for:
        - Policy requires quarterly review (matches control objective frequency)
        - Procedure defines what "unused account" means (e.g., no login for 90 days)
        # => Vague definitions in procedure are a design weakness — "unused" must be operationalized
        - Revocation timeframe documented (5 business days per objective)
        - Approval chain documented (who must approve; who performs revocation)
 
    - procedure: Interview IT Security Manager about how the review is actually performed
      evidence_type: Inquiry
      # => Inquiry = asking people; less reliable than inspection alone
      questions:
        - How are accounts identified as unused?
        - How is the review evidence captured (spreadsheet, tool, ticket)?
        - What happens when a manager does not respond to certification request?
      design_gap_indicator: If the process depends entirely on human memory, not documented procedure
 
  design_conclusion_options:
    - Effective design: Control design is capable of achieving objective
    - Design weakness: Control as designed has gaps — log as finding, test effectiveness anyway
    # => A design weakness does not stop effectiveness testing — both findings reported separately
 
test_of_effectiveness:
  objective: Confirm the control operated as designed during January–March 2026 (Q1 audit period)
  # => ToE tests whether the control actually ran — not just whether it was designed to
  procedures:
    - procedure: Obtain Q1 2026 access review evidence (certification reports, tickets, email approvals)
      evidence_type: Inspection
      sample_size: All instances (quarterly review = 1 instance in period; test all)
      # => For low-frequency controls, test all instances — no sampling needed
      what_to_verify:
        - Review was initiated within first two weeks of the quarter
        - All privileged accounts were included in the review
        - Each account has a documented approval or revocation decision
 
    - procedure: Select sample of accounts flagged for revocation; verify revocation date in Okta
      evidence_type: Re-performance
      # => Re-performance = independently replicating the control to verify it produced correct result
      sample_size: All revocations in period (if ≤20); statistical sample (if >20)
      what_to_verify: Revocation date is within 5 business days of flagging (per objective)
      # => If any revocation exceeded 5 business days, record as effectiveness exception
 
    - procedure: Verify Q1 review was approved by IT Security Manager (required per procedure)
      evidence_type: Inspection of approval record
      # => Approval documentation is required for the control to be considered complete
 
  effectiveness_conclusion_options:
    - Operating effectively: Control ran as designed; no exceptions
    - Exception noted: Control ran but one or more instances did not meet criteria → finding
    - Control not operating: No evidence control ran in period → material weakness
 
findings_documentation:
  finding_format: 4Cs — Condition, Criteria, Cause, Effect (see Example 21)
  # => All findings must follow the 4Cs format for consistency and defensibility

# Meridian Health IT Audit — Change Management Process
# Audit Reference: IA-2026-003
 
audit_memo:
  audit_objective:
    statement: >
      Assess whether Meridian Health's change management process provides
      reasonable assurance that production changes are authorized, tested,
      and implemented without unauthorized modification to PHI systems.
    # => Objective is a testable assertion — "provides reasonable assurance" is auditable
    # => "Determine if change management is good" is not a testable objective
    trigger: Two unauthorized production changes in Q1 2026
    risk_area: BAI06 — Managed IT Changes (COBIT 2019)
    # => Referencing COBIT objective links audit to governance framework
 
  scope:
    in_scope:
      - Change management policy and procedure documentation (current versions)
      - All production changes to PHI-adjacent systems during Jan–Mar 2026
      # => PHI-adjacent = EHR system, PACS, billing system, identity management
      - Change Advisory Board meeting minutes and approval records (Q1 2026)
      - Deployment logs for in-scope systems (Q1 2026)
      - Post-implementation review records
    out_of_scope:
      - Development and test environment changes
      # => Test environment changes carry lower risk — separate audit if needed
      - Non-PHI systems (HR system, marketing tools)
      - Changes approved and implemented before January 2026
      # => Scope boundary prevents scope creep — document explicitly
    rationale_for_scope:
      - Scope limited to PHI systems because unauthorized access to PHI is the board's concern
      - Q1 2026 selected because it contains the two unauthorized changes that triggered the audit
 
  evidence_types:
    observation:
      definition: Directly watching a process or procedure being performed
      # => Observation provides the strongest evidence that a process actually operates as described
      meridian_health_use: Observe a CAB meeting in real time to assess authorization rigor
      limitation: Audit presence may alter behavior (Hawthorne effect)
 
    inquiry:
      definition: Asking people questions about how processes work
      # => Inquiry is weakest evidence type — people may be mistaken or misleading
      meridian_health_use: Interview Change Manager, IT Operations Manager, system owners
      limitation: Inquiry alone is insufficient — must be corroborated by inspection or re-performance
 
    inspection:
      definition: Examining documents, records, reports, or system outputs
      # => Inspection provides strong evidence and produces documentary audit trail
      meridian_health_use:
        - Review change request tickets in ITSM system (ServiceNow)
        - Review CAB approval emails and meeting minutes
        - Review deployment pipeline logs showing who deployed what and when
      limitation: Documents can be fabricated — corroborate with system-generated logs
 
    re_performance:
      definition: Independently replicating the control or process to verify it produces correct results
      # => Strongest evidence type — auditor confirms outcome independently
      meridian_health_use:
        - Pull deployment logs independently from AWS CloudTrail
        - Cross-reference against approved change request tickets
        - Identify deployments with no corresponding approved change request
        # => This is how the two unauthorized changes will be confirmed as audit findings
 
  audit_timeline:
    planning_phase: May 21–28, 2026 (scope agreement with management)
    fieldwork_phase: June 1–21, 2026 (evidence collection)
    reporting_phase: June 22 – July 10, 2026 (findings and recommendations)
    management_response_deadline: July 17, 2026
    # => Management must respond to each finding before the final report is issued
    final_report_to_board: July 24, 2026

# AcmeSoft Audit Finding — AF-2026-007
 
finding_metadata:
  audit_reference: IA-2026-002 (Privileged Access Management Audit)
  finding_id: AF-2026-007
  severity: High
  # => Severity based on risk impact: critical/high/medium/low
  # => Missing quarterly review for a period = High (not Critical because no breach confirmed)
  finding_date: 2026-05-21
  control_reference: CO-PAM-001
 
four_cs:
  condition:
    label: "1. Condition: What the auditor found"
    # => Condition is factual — no interpretation or blame; just what the evidence shows
    statement: >
      The Q1 2026 (January–March) privileged access review for production systems
      was not completed. As of the audit date (May 21, 2026), no review evidence
      (access certification report, revocation tickets, or manager approvals) exists
      in Okta, ServiceNow, or the shared audit evidence folder for Q1 2026.
    evidence:
      - Okta access review history: no Q1 2026 review record
      - ServiceNow query for access review tickets (Jan–Mar 2026): zero results
      - Interview with IT Security Manager (May 19, 2026): confirmed review was not performed
    # => Three independent evidence sources confirm the condition — not a single inquiry
 
  criteria:
    label: "2. Criteria: What should be"
    # => Criteria reference the specific policy, standard, or control objective violated
    statement: >
      Per Control Objective CO-PAM-001 (Privileged Access Management) and the
      AcmeSoft Access Control Policy v2.1 Section 4.3, privileged access must be
      reviewed quarterly. The Q1 2026 review should have been completed by
      March 31, 2026.
    sources:
      - CO-PAM-001 (reviewed in Example 17)
      - AcmeSoft Access Control Policy v2.1, Section 4.3
      - SOC 2 Trust Services Criteria CC6.1 (logical access review)
    # => Multiple criteria sources strengthen the finding and anticipate management counter-arguments
 
  cause:
    label: "3. Cause: Why the gap exists"
    # => Cause explains the root reason — required for management to fix the issue correctly
    # => Without cause, management fixes the symptom (completing the missed review) not the problem
    statement: >
      The IT Security Manager role was vacant from December 2025 to April 2026.
      No backup owner was designated for the quarterly review, and no compensating
      procedure existed for critical controls during staff vacancies.
    root_cause: Absence of a backup control owner and no documented procedure for
      control continuity during role vacancies
    # => Root cause points to a process gap, not just an individual failure
    contributing_factor: No automated reminder or escalation in ServiceNow for overdue control tasks
 
  effect:
    label: "4. Effect: The consequence"
    # => Effect explains why the finding matters — enables management to prioritize remediation
    actual_effect: >
      Three engineers retained production database administrator access after transferring
      to non-production roles in January and February 2026, representing a period of
      30–60 days of unauthorized standing privileged access.
    potential_effect: >
      Unauthorized privileged access creates risk of accidental or intentional data
      modification, data exfiltration, or system disruption. PHI exposure would trigger
      HIPAA breach notification obligations.
    # => Quantify the effect where possible — "three engineers for 30–60 days" is more compelling
    # => than "unauthorized access may have occurred"
 
recommendation:
  immediate: Complete the Q1 2026 access review and revoke any identified unauthorized access within 10 business days
  short_term: Designate a backup owner for each critical control with documented on-call procedure
  long_term: Configure ServiceNow to automatically escalate overdue critical control tasks to the CISO after 14 days
  # => Three-horizon recommendations (immediate/short-term/long-term) give management a clear path
 
management_response_due: 2026-06-04

# Nexatech Compliance Framework Mapping — Governance Implications
 
frameworks_in_scope:
  ISO_27001_2022:
    type: International Standard (certification-based)
    # => ISO 27001 is audited by an accredited certification body — results in a certificate
    primary_driver: Customer enterprise sales requirement + EU GDPR alignment
    scope: Information security management system (ISMS) — all information assets
    audit_cycle: Annual surveillance + 3-year recertification
 
  SOC_2:
    type: Attestation report (US-origin, AICPA)
    # => SOC 2 is a CPA-attested report — not a certificate, but widely accepted by US customers
    primary_driver: US enterprise customer due diligence requirement
    scope: One or more Trust Services Criteria (Security is mandatory; Availability, etc. optional)
    audit_cycle: Type I (point in time) or Type II (6–12 month period)
    # => Type II is preferred — shows controls operated consistently, not just exist
 
  NIST_CSF_2_0:
    type: Voluntary framework (US government, globally adopted)
    # => NIST CSF is not a certification — it is a self-assessment and communication tool
    primary_driver: Internal risk management language; increasingly required by US federal contractors
    scope: Cybersecurity risk management — six functions (Govern, Identify, Protect, Detect, Respond, Recover)
    # => CSF 2.0 added "Govern" as sixth function in 2024
    audit_cycle: Self-assessment; no mandated external audit
 
  PCI_DSS_v4_0:
    type: Industry standard (Payment Card Industry Security Standards Council)
    # => PCI DSS is mandatory for any entity storing, processing, or transmitting cardholder data
    primary_driver: Payment card processing (Nexatech processes cardholder data)
    scope: Cardholder data environment (CDE) and systems that connect to it
    audit_cycle: Annual QSA assessment (Level 1 merchants) or annual self-assessment (lower levels)
 
control_harmonization_strategy:
  principle: Implement one set of controls that satisfies multiple frameworks simultaneously
  # => One access control review satisfies ISO 27001 A.5.18, SOC 2 CC6.3, and PCI DSS Req. 7
  primary_framework: ISO 27001
  # => ISO 27001 chosen as the primary framework because its ISMS structure organizes all other controls
  mapping_approach:
    - Implement controls to ISO 27001 standard
    - Document which SOC 2, NIST CSF, and PCI DSS requirements each control satisfies
    - Single audit evidence package reused across multiple assessments
  # => This approach reduces audit preparation time and control documentation overhead
 
gap_areas:
  PCI_DSS_specific:
    - Network segmentation requirements (scoping the CDE) — not required by ISO 27001
    # => PCI DSS Req. 1 has very specific network segmentation requirements beyond ISO 27001 scope
  SOC_2_specific:
    - Availability Trust Service Criteria (uptime commitments) — not in ISO 27001 core
    # => Availability criteria require documented SLA commitments and monitoring that ISO 27001 does not mandate

# AcmeSoft IT Governance KPI Dashboard — Board Reporting Set
 
reporting_frequency: Quarterly
# => Quarterly reporting aligns with governance committee cadence (see Example 8)
audience: Board IT Committee
format: Dashboard with trend (last 4 quarters) + traffic-light status (Red/Amber/Green)
# => Traffic-light + trend is the minimum board-friendly format — avoids data dumps
 
kpis:
  KPI_1_it_project_delivery_rate:
    definition: Percentage of IT projects delivering on time, on budget, and within scope
    formula: "(Projects delivered on time AND budget AND scope ÷ Total projects completed) × 100"
    # => Conjunction is intentional — partial success is not counted as delivered
    target: ≥ 80%
    # => 100% is unrealistic; 80% is a recognized industry benchmark for mature PMOs
    measurement_frequency: Quarterly
    data_source: PMO project tracking system (Jira Projects)
    current_value: 67%
    status: Amber
    # => Amber = below target but improving; Red = below target and declining
    board_action_threshold: Below 60% for two consecutive quarters triggers board discussion
 
  KPI_2_risk_closure_rate:
    definition: Percentage of overdue risk treatment plan items closed by their due date
    formula: "(Risk treatment items closed by due date ÷ Total risk treatment items due) × 100"
    # => Measures whether management is acting on identified risks — not just identifying them
    target: ≥ 85%
    measurement_frequency: Quarterly
    data_source: IT Risk Register (see Example 13)
    current_value: 72%
    status: Amber
    note: Three critical-risk items slipped due to staff vacancy — see context in board narrative
    # => KPIs need narrative context — a number without explanation misleads more than informs
 
  KPI_3_audit_finding_aging:
    definition: Percentage of open audit findings overdue past their agreed remediation date
    formula: "(Open findings past remediation date ÷ Total open findings) × 100"
    # => Lower is better — finding aging indicates management is not acting on audit results
    target: ≤ 10%
    # => Some slippage is normal; above 10% suggests systemic follow-up failure
    measurement_frequency: Quarterly
    data_source: Internal Audit tracking log
    current_value: 8%
    status: Green
 
  KPI_4_change_success_rate:
    definition: Percentage of IT changes implemented without causing a service incident
    formula: "(Changes with no resulting incident within 72 hours ÷ Total changes) × 100"
    # => 72-hour window is standard — changes causing incidents after 72 hours are usually unrelated
    target: ≥ 95%
    measurement_frequency: Monthly (reported quarterly as trend)
    data_source: Change Management system (ServiceNow) + Incident Management correlation
    current_value: 97%
    status: Green
    note: Two failed changes in Q1 both linked to emergency changes without CAB approval
    # => Narrative connects the metric to a governance action (CAB bypass = elevated risk)
 
  KPI_5_sla_compliance:
    definition: Percentage of IT service SLA targets met across all in-scope services
    formula: "(SLA targets met ÷ Total SLA targets measured) × 100"
    # => Aggregates across all services — drill-down by service available in management report
    target: ≥ 98%
    measurement_frequency: Monthly (reported quarterly as aggregate)
    data_source: ITSM platform SLA dashboard (ServiceNow)
    current_value: 99.2%
    status: Green
 
reporting_format:
  executive_summary: One paragraph narrative interpreting the five KPIs together
  # => Board members read the narrative first — metrics provide supporting evidence
  trend_chart: Last 4 quarters for each KPI
  # => Trend reveals whether the organization is improving or declining — single data point misleads
  actions_required: Bullet list of governance decisions or management actions needed

# Meridian Health SLA — Electronic Health Record System
 
sla_metadata:
  service_name: Electronic Health Record (EHR) System
  service_owner: IT Operations Manager
  customer: Clinical Operations Department
  # => SLA is between a service provider (IT) and a customer (business unit)
  effective_date: 2026-06-01
  review_date: 2027-06-01
  # => Annual review — align with budget and contract renewal cycles
  version: "1.0"
  approvers: [IT Operations Manager, Chief Medical Officer]
  # => Both service owner and customer must approve — prevents IT setting unrealistic targets
 
service_description:
  what_it_covers: >
    Availability, performance, and support for the Meridian EHR system
    including patient record access, clinical documentation, and pharmacy
    order management functions.
  # => Explicit description prevents scope disputes ("is the patient portal part of this SLA?")
  what_it_excludes:
    - Third-party lab result integration (separate SLA with lab vendor)
    - EHR mobile app (separate SLA — different deployment target)
    # => Explicit exclusions are as important as inclusions
 
availability_target:
  target: 99.9% per calendar month
  # => 99.9% = ~44 minutes downtime per month; appropriate for clinical-critical systems
  # => 99.99% would be ~4 minutes — may require active-active architecture costing 3× more
  measurement_window: 24 hours × 7 days
  # => EHR must be available outside business hours — clinical staff work nights and weekends
  exclusions_from_downtime:
    - Scheduled maintenance windows: Sunday 02:00–04:00 WITA
    # => Scheduled windows excluded from availability calculation — notify users 5 days prior
    - Events outside Meridian Health's reasonable control (upstream cloud provider outage > 30 min)
    # => Force majeure exclusion — prevents penalizing IT for AWS us-east-1 region failure
  measurement_tool: Synthetic monitoring via UptimeRobot (checks every 60 seconds)
  reporting: Monthly availability report sent to Clinical Operations Director by 5th business day
 
incident_response_times:
  # => Response time = time from ticket creation to IT acknowledging the incident
  # => Resolution time = time from acknowledgement to service restoration
  P1_critical:
    definition: EHR completely unavailable or patient data inaccessible
    # => P1 = clinical workflow stopped; patient safety risk
    response_time: 15 minutes
    # => 15-minute response requires 24/7 on-call rotation — confirm roster exists
    resolution_target: 4 hours
    escalation: Automatic page to IT Director and CMO at 30 minutes
    # => Clinical system P1 requires executive awareness — not just IT ownership
 
  P2_high:
    definition: Major function impaired (e.g., order entry slow or pharmacy module unavailable)
    response_time: 1 hour
    resolution_target: 8 hours (within business hours); next business day (outside hours)
    escalation: IT Operations Manager notified at 4 hours
 
  P3_medium:
    definition: Minor function impaired; workaround available
    response_time: 4 hours (business hours)
    resolution_target: 3 business days
    # => 3-day resolution is acceptable when clinical workflow continues via workaround
 
sla_credits:
  availability_below_99_5_percent:
    credit: 5% of monthly IT service fee for the EHR
    # => Financial credit creates IT accountability without punitive escalation
  availability_below_99_0_percent:
    credit: 15% of monthly IT service fee
  p1_resolution_exceeding_8_hours:
    credit: $500 per incident beyond 8 hours
    # => Per-incident credit for P1 overruns focuses remediation effort on highest-impact failures
 
review_cadence:
  monthly: SLA performance report (IT to Clinical Operations)
  quarterly: SLA review meeting (IT Operations Manager + Clinical Operations Director)
  annual: Full SLA renegotiation and re-approval
  # => Annual renegotiation allows targets to evolve as system matures and trust is established

# Nexatech Change Management Governance — Maturity Model Assessment
 
governance_area: IT Change Management (COBIT BAI06 — Managed IT Changes)
assessed_date: 2026-05-21
current_maturity_level: 2
target_maturity_level: 4
target_date: 2027-Q2
 
maturity_levels:
  level_1_initial:
    name: Initial
    descriptor: >
      Change management exists but is entirely ad hoc. There is no formal
      process, no change request documentation, and changes are made based
      on individual judgment.
    characteristics:
      - No change request form or ticketing system
      - No change approval process
      - No post-implementation review
      - Success depends on individual skill, not process
    risk_implication: Every production change is a potential uncontrolled event
    # => At Level 1, the organization cannot distinguish unauthorized from authorized changes
    nexatech_evidence_if_here: No CAB exists; engineers deploy directly to production at will
 
  level_2_repeatable:
    name: Repeatable
    descriptor: >
      Some change management practices exist and are repeated informally.
      Changes are generally documented but the process is inconsistent and
      not formally defined.
    characteristics:
      - Basic change request tickets created in ServiceNow
      - Informal approval via Slack message or email
      - No formal CAB; approvals happen ad hoc
      - Some post-change testing; no formal PIR
    risk_implication: Some visibility into changes but authorization cannot be reliably audited
    nexatech_current_state: true
    # => Nexatech is currently at Level 2 — documented informally but not standardized
    gaps_to_level_3:
      - Formalize CAB with defined composition and meeting cadence
      - Document change management procedure (not just policy)
      - Define change categories (standard/normal/emergency) with different approval paths
 
  level_3_defined:
    name: Defined
    descriptor: >
      The change management process is formally documented, standardized
      across the organization, and consistently followed.
    characteristics:
      - Documented Change Management Policy and Procedure (Tier 1 + Tier 3, per Example 10)
      - CAB formally established with charter (Example 8)
      - Three change types defined: standard (pre-approved), normal (CAB approval), emergency
      - Change success rate tracked and reported (KPI, Example 23)
      - Post-implementation review mandatory for all normal and emergency changes
    risk_implication: Change risk is predictable; unauthorized changes are detectable
    effort_to_achieve: 3–6 months; requires PMO support and tool configuration in ServiceNow
 
  level_4_managed:
    name: Managed
    descriptor: >
      Change management performance is measured quantitatively. Process
      deviations are detected and corrected. Management makes decisions
      based on change metrics rather than intuition.
    characteristics:
      - Change success rate, change frequency, and emergency change ratio tracked (KPIs)
      - Root cause analysis mandatory for all failed changes
      - Change risk scoring applied to each request; high-risk changes require enhanced review
      - Control testing of CAB authorization performed quarterly (see Example 19)
      - Management dashboard updated in real time from ServiceNow data
    risk_implication: Change risk is controlled and measurable; board can assess with confidence
    target_for_nexatech: true
 
  level_5_optimizing:
    name: Optimizing
    descriptor: >
      Change management continuously improves based on data. The organization
      proactively identifies failure patterns and refines the process. Change
      lead times are reduced while risk is maintained or decreased.
    characteristics:
      - AI-assisted change risk scoring in ServiceNow
      - Automated regression test suite gates deployments before CAB review
      - Change process benchmarked against industry peers (ITIL maturity benchmark)
      - Change management improvement ideas tracked in formal backlog and prioritized quarterly
    when_to_target: After Level 4 is sustained for two quarters; appropriate for mature organizations
    # => Jumping to Level 5 without Level 4 foundation produces automation that bypasses governance
 
improvement_roadmap:
  current_to_level_3:
    actions:
      - Establish formal CAB charter and composition (Q3 2026)
      - Document Change Management Procedure in ServiceNow (Q3 2026)
      - Define three change categories in ServiceNow workflow (Q3 2026)
    success_criteria: Zero unauthorized changes in 90-day period after procedure publication
 
  level_3_to_level_4:
    actions:
      - Implement change KPI dashboard (Q4 2026)
      - Add mandatory RCA template for failed changes in ServiceNow (Q4 2026)
      - Quarterly control testing of CAB authorization (from Q1 2027)
    success_criteria: Change KPIs reported to board for two consecutive quarters

# AcmeSoft IT Governance Stakeholder Communication Plan
 
stakeholders:
 
  board_it_committee:
    audience: Board directors (3 members)
    primary_need: Strategic oversight — are IT investments delivering value and risks within appetite?
    # => Board does not need operational detail — they need assurance and exception reporting
    communication_frequency: Quarterly
    format: 2-page executive summary + 1-page dashboard (KPIs + heat map)
    # => Two pages maximum — board members review many documents; length signals disrespect
    content:
      - IT strategy alignment summary (one paragraph)
      - Five governance KPIs with traffic-light status (see Example 23)
      - Risk heat map — critical and high risks only
      - Compliance status (certifications, audit findings, regulatory updates)
      - Material IT investments approved/rejected in the period
    what_to_exclude:
      - Operational metrics (incident volumes, ticket counts) — these belong in management reporting
      # => Incident volumes belong in IT management reporting, not board governance reporting
    owner: CIO (reviews and signs off before distribution)
    delivery_method: Board portal (secure document sharing) + in-person presentation
 
  c_suite:
    audience: CEO, CFO, COO, CISO (5 members)
    primary_need: Executive management — is IT supporting business operations effectively?
    communication_frequency: Monthly
    format: 4-page management report + verbal summary at monthly leadership meeting
    content:
      - IT performance against SLAs (see Example 24)
      - Active risk treatment plan status (Example 16)
      - IT project portfolio status (on track / at risk / delayed)
      - Significant incidents in the period (P1/P2) + root cause summary
      - Upcoming major changes requiring executive awareness
    owner: CIO
    delivery_method: Email + leadership meeting agenda item
 
  business_units:
    audience: Department heads and business unit leads (8 leaders)
    primary_need: Operational awareness — how is IT affecting their team's work?
    communication_frequency: Monthly
    format: 1-page service report per business unit
    content:
      - SLA performance for IT services used by that business unit
      - Open incidents affecting that business unit (status + ETA)
      - Upcoming changes that will affect their workflows (2-week forward look)
      # => Forward look is the most valued item for business units — surprises reduce trust
    owner: IT Service Manager
    delivery_method: Email distribution + available in IT service portal
 
  it_teams:
    audience: IT engineers, analysts, service desk (60 staff)
    primary_need: Operational clarity — what are the priorities and how are we performing?
    communication_frequency: Weekly (brief) + Monthly (detailed)
    format: Weekly: 10-minute team standup + async Slack summary; Monthly: team review meeting
    content:
      - Change calendar for upcoming week
      - Open incident and problem tickets requiring action
      - Policy and procedure updates
      - Training requirements (compliance, security awareness)
    owner: IT Operations Manager
    delivery_method: Slack channel + ITSM system notifications
 
  auditors:
    audience: Internal auditors + external auditors (SOC 2 CPA firm)
    primary_need: Audit assurance — is the governance framework operating as documented?
    communication_frequency: On-request + annual structured evidence package
    format: Structured evidence package (see Example 20 for evidence types)
    content:
      - Policy and procedure documentation (current versions)
      - Control evidence (access review reports, CAB minutes, risk register)
      - KPI trend data for audit period
      - Prior audit finding remediation status
    owner: IT Governance Manager (internal); CIO (external auditor relationship)
    delivery_method: Secure file sharing portal (never email for audit evidence)
    # => Audit evidence must be tamper-evident — use a portal with access logging
 
communication_calendar:
  weekly: IT team standup (IT Operations Manager)
  monthly: Management report (CIO → C-suite) + BU service reports
  quarterly: Board IT Committee report + IT Risk Committee report
  annual: Auditor evidence package + full SLA review + policy review cycle

# Nexatech Board IT Committee Charter
 
<!-- => Charter header: name, version, approval authority — must be traceable -->
 
**Version:** 1.0 | **Approved by:** Board of Directors | **Effective:** 2026-06-01
**Review cycle:** Annual | **Owner:** Company Secretary
 
---
 
## 1. Purpose
 
<!-- => Purpose defines why this body exists — the governance problem it solves -->
 
The Board IT Committee provides governance oversight of Nexatech's
information technology strategy, risk, and compliance on behalf of the
Board of Directors. It ensures IT investments deliver value, IT risks
are managed within the board-approved risk appetite, and IT operations
comply with applicable regulations.
 
## 2. Scope of Authority
 
<!-- => Authority defines what the committee can decide vs. what it recommends -->
 
**Decision authority (the committee may approve without full board vote):**
 
- IT strategy (subject to annual board ratification)
- IT investments up to $500,000 per project
 
<!-- => Delegated approval threshold must be documented — prevents scope creep -->
 
- IT risk appetite (subject to annual board ratification)
- IT governance framework selection and changes
 
**Advisory role (the committee recommends; full board decides):**
 
- IT investments exceeding $500,000
- Material changes to IT risk appetite
 
<!-- => Above threshold = full board — committee is advisory, not decision-making -->
 
**Not in scope (management authority — not committee authority):**
 
- IT project execution decisions
- Vendor selection below threshold
- Day-to-day IT operational decisions
 
## 3. Composition
 
<!-- => Composition defines who must be on the committee and what quorum requires -->
 
| Role                         | Requirement                   | Voting Rights |
| ---------------------------- | ----------------------------- | ------------- |
| Chair (independent director) | Minimum: 1                    | Yes           |
| Independent board director   | Minimum: 1 additional         | Yes           |
| CIO                          | Standing attendee             | No (advisory) |
| CISO                         | Attendee when agenda relevant | No            |
| External IT advisor          | Optional; at board discretion | No            |
 
<!-- => CIO attends as advisor — voting reserved for board members (independence principle) -->
 
**Quorum:** Both voting members must be present for decisions.
 
## 4. Meeting Cadence
 
<!-- => Documented cadence creates accountability — unscheduled meetings invite indefinite deferral -->
 
- **Regular meetings:** Quarterly (aligned with board calendar)
- **Special meetings:** Called by Chair or CEO when material IT risk event occurs
- **Meeting materials:** Distributed minimum 5 business days before meeting
- **Minutes:** Circulated within 10 business days; approved at next meeting
 
## 5. Reporting Relationships
 
<!-- => Reporting lines determine where escalations go and who receives committee output -->
 
- The committee reports to the full Board of Directors
- The committee receives reports from the CIO, CISO, and IT Audit
- The committee's decisions are communicated to the CEO and CIO within 2 business days
 
## 6. Escalation Path
 
<!-- => Escalation path prevents decisions from being held indefinitely -->
 
1. IT management decisions that exceed management authority → IT Risk Committee → Executive Steering Committee → Board IT Committee
2. Board IT Committee decisions that exceed delegated authority → Full Board of Directors
3. Material IT security incident → CISO notifies Chair within 24 hours → Emergency session convened if required
 
## 7. Amendment
 
<!-- => Charter amendment process prevents ad hoc changes to governance authority -->
 
Amendments require approval by the full Board of Directors. Minor
editorial changes may be approved by the Chair with notification to
the full board at the next meeting.

# AcmeSoft IT Investment Decision Framework — Project Intake Form
 
framework_metadata:
  version: "1.0"
  approved_by: Board IT Committee
  effective_date: 2026-06-01
  # => Approval tiers and thresholds must be board-approved to have governance authority
 
approval_tiers:
  operational:
    threshold: Under $50,000
    # => Operational tier = routine maintenance and minor improvements; no steering committee needed
    approver: IT Director
    time_to_decision: 5 business days
    business_case_required: Lightweight (one-page memo)
 
  tactical:
    threshold: $50,000 – $500,000
    # => Tactical tier = significant investment requiring cross-functional alignment
    approver: Executive Steering Committee
    time_to_decision: 15 business days
    business_case_required: Full (standard template including ROI and risk sections)
 
  strategic:
    threshold: Above $500,000 OR strategic classification (see below)
    # => Strategic tier = material investment; board-level governance required
    approver: Board IT Committee
    time_to_decision: One full board cycle (up to 90 days)
    business_case_required: Full + external validation recommended
    strategic_classification_triggers:
      - New technology platform affecting entire organization
      - Investment changing AcmeSoft's core data or security architecture
      - Investment required for regulatory compliance (mandatory regardless of cost)
      # => Some investments are strategic regardless of cost — compliance mandates get board visibility
 
intake_forms:
  proposal_A:
    project_name: Deploy CrowdStrike Falcon EDR
    # => From RISK-003 treatment plan (Example 16)
    business_case_summary: >
      Deploy endpoint detection and response tool across 200 company
      devices to mitigate ransomware risk currently rated Critical (score 16).
    # => Business case must summarize the problem, not just the solution
    strategic_alignment_score: 4 out of 5
    # => Scale: 1 (no alignment) to 5 (directly enables strategic objective)
    # => Score 4: directly addresses board-approved risk appetite breach
    scoring_criteria:
      - Supports IT security strategy: Yes (score +2)
      - Required by compliance obligation: No (score +0)
      - Addresses board-reported risk: Yes (score +2)
      # => Transparent scoring rubric prevents subjective strategic alignment claims
    risk_rating: High
    # => Risk rating = risk of NOT doing this project (i.e., residual risk if deferred)
    estimated_value:
      cost: 52800_usd_annual
      risk_avoided: 500000_usd_estimated_ransomware_recovery_cost
      roi: 9.5x
      # => ROI = expected loss avoided ÷ treatment cost (from Example 16)
    estimated_start: 2026-06-01
    governance_approval_tier: Tactical
    # => $52.8K = within Tactical tier ($50K–$500K); Executive Steering Committee approves
    routed_to: Executive Steering Committee
    priority: Urgent (board-reported risk breach)
    # => Urgency flag routes to next available ESC meeting rather than scheduled cycle
 
  proposal_B:
    project_name: Migrate on-premise file server to SharePoint Online
    business_case_summary: >
      Replace aging on-premise file server (5 years old, no vendor support)
      with SharePoint Online to reduce infrastructure costs and improve
      remote access for 200 employees.
    strategic_alignment_score: 3 out of 5
    scoring_criteria:
      - Supports IT infrastructure modernization strategy: Yes (score +2)
      - Required by compliance obligation: No (score +0)
      - Addresses board-reported risk: No (score +1 for operational risk reduction)
    risk_rating: Medium
    estimated_value:
      cost: 45000_usd_one_time_plus_18000_usd_annual
      cost_avoided: 35000_usd_annual_server_maintenance
      payback_period: 3_years
    estimated_start: 2026-Q3
    governance_approval_tier: Tactical
    # => Total cost (one-time + year-1 annual) = $63K; within Tactical tier
    routed_to: Executive Steering Committee
    priority: Normal (next scheduled cycle)
 
  proposal_C:
    project_name: Implement enterprise GRC platform (ServiceNow IRM)
    business_case_summary: >
      Replace spreadsheet-based risk register and compliance tracking with
      ServiceNow Integrated Risk Management module to automate control
      testing, risk reporting, and audit evidence collection at scale.
    strategic_alignment_score: 5 out of 5
    scoring_criteria:
      - Directly enables IT governance maturity improvement: Yes (score +2)
      - Required for SOC 2 Type II efficiency: Yes (score +2)
      - Addresses board-reported concern (audit finding aging KPI): Yes (score +1)
    risk_rating: Low
    # => Risk of deferral is low — current spreadsheet approach is functional if labor-intensive
    estimated_value:
      cost: 180000_usd_annual_license_plus_120000_usd_implementation
      # => Year-1 total: $300K; within Tactical tier; Year-2+: $180K/year
      efficiency_gain: 0.5_FTE_annual_audit_preparation_time_saved
      estimated_value_usd: 75000_usd_annual_labor_savings
    governance_approval_tier: Tactical
    # => $300K year-1 cost is within Tactical tier ($50K–$500K)
    routed_to: Executive Steering Committee
    priority: Normal (next scheduled cycle)
    # => Lower priority than Proposal A — does not address a board-reported risk breach