# HAV Seafood - IT Service, Change & Control Framework

## Purpose

This workbook defines the static **IT Service, Change & Control Framework** for HAV Seafood.

It belongs to **Phase 1 - Business Architecture**:

**1. Business architecture -> 2. Stories -> 3. Operational dataset**

The framework defines how IT services, service requests, incidents, problems, changes, approvals, controls, exceptions, escalations, service-level targets and recurring IT processes are structurally designed.

It intentionally contains **no operational IT history** such as help-desk tickets, actual incidents, changes, approvals, alerts, outages, control executions, vendor cases, response-time results or SLA/KPI history.

---

## Architecture scope at a glance

The workbook contains:

- **18 internal IT services**;
- **38 service-to-system/infrastructure dependency relationships**;
- **22 reusable IT request types**;
- **14 incident categories**;
- **4 incident priorities** and a **16-row impact/urgency matrix**;
- **14 permitted incident lifecycle transitions**;
- **7 problem categories**;
- **9 change types** across Standard, Normal and Emergency classes;
- **4 change-risk classes** and **13 change lifecycle transitions**;
- **15 static change-approval rules**;
- **15 position-to-IT-authority mappings**;
- **32 IT control requirements**;
- **10 IT-specific segregation-of-duties rules**;
- **5 escalation classes** and **13 exception types**;
- **14 internal service-level definitions**;
- **24 IT processes** with **120 static process steps**;
- **101 system-to-process applicability relationships** covering all 13 existing enterprise systems;
- **14 cross-domain IT/business handoff definitions**.

The framework is deliberately proportionate to a 92-person manufacturer. It provides enough structure for realistic later operational data without creating an enterprise-scale ITSM bureaucracy.

---

## Core model

The service-management model is:

`IT Service -> Request Type / Incident Category -> Priority -> Resolution / Escalation`

The problem model is:

`Repeated or Material Incident Pattern -> Problem -> Root-Cause Analysis -> Workaround / Corrective Change`

The change model is:

`Change Request -> Change Type -> Risk Classification -> Approval -> Implementation -> Validation -> Closure / Rollback`

The control model is:

`IT Process -> Control Requirement -> Future Control Execution / Evidence -> Exception / Escalation`

---

## Key conceptual boundaries

The architecture deliberately keeps the following concepts separate:

`IT Service != Enterprise System`

`IT Service != Infrastructure Service`

`Service Request Type != Service Request`

`Incident Category != Incident`

`Incident != Problem`

`Problem != Root Cause`

`Change Type != Change`

`Change Approval Rule != Approval Event`

`Control != Control Execution`

`Exception Type != Exception Case`

`Service-Level Target != Service-Level Result`

`Technical Ownership != Business Data Ownership`

`Technical Administration != Business Approval Authority`

These distinctions must be preserved in later operational datasets.

---

## IT service model

### `IT_Service_Catalog`
Defines the 18 internal IT services that HAV Seafood IT provides to employees and business functions. Services include identity/access, workplace/endpoints, Microsoft 365, ERP, MES, QMS, CMMS, People & Payroll, CRM, reporting, label/print, cold-chain technology, network/connectivity, backup/recovery, security, integrations, banking technical access and IT asset lifecycle.

### `Service_Dependencies`
Connects IT services to the existing `ESYS-*` enterprise systems and `ITSVC-*` infrastructure services.

An IT Service is a user/business-facing support concept. It does not replace the system or infrastructure master.

### `Request_Types`
Defines reusable request categories, approval expectations and target fulfilment classes. Actual requests belong to Phase 3.

---

## Incident and problem framework

### `Incident_Categories`
Defines the reusable incident taxonomy across applications, integrations, identity/access, endpoints, networking, operational technology, backup/recovery, security, vendors and monitoring.

### `Incident_Priority_Framework`
Defines P1 Critical through P4 Low based on business impact and urgency.

### `Impact_Urgency_Matrix`
Provides the static mapping from impact + urgency to the resulting priority. Priority is not fixed solely by incident category.

### `Incident_Lifecycle`
Defines permitted status transitions such as New -> Acknowledged -> In Progress -> Resolved -> Closed, including pending, escalation and security-assessment paths.

### `Problem_Framework`
Defines when recurring or material incidents should become a problem/root-cause workstream. It contains no current problems.

---

## Change framework

### `Change_Types`
Defines nine reusable technical change types across three classes:

- Standard;
- Normal;
- Emergency.

### `Change_Risk_Classification`
Defines Low, Moderate, High and Critical change risk.

### `Change_Lifecycle`
Defines the permitted path from request and assessment through approval, scheduling, implementation, validation, rollback or closure.

### `Change_Approval_Rules`
Defines business, IT and exceptional executive approval expectations by change class/risk/scope.

HAV Seafood does not use an elaborate separate Change Advisory Board. Authority is attached to the existing management/position structure.

---

## Authority and control

### `Position_Authority`
Maps existing HR-owned positions to IT authority classes. Employee incumbency is intentionally not copied into this architecture; actual approver identity is resolved from HR at operational time.

### `IT_Control_Framework`
Defines 32 recurring IT controls across service management, change, access, security, infrastructure, continuity, integration and lifecycle governance.

Where a detailed security requirement already exists in the Identity, Access & Information Security Framework, the IT control references that `SECCTRL-*` requirement rather than redefining it.

### `IT_Segregation_of_Duties`
Defines ten IT-specific SoD rules, including separation of privileged access request/approval, high-risk change implementation/approval, backup administration/restore validation and technical administration/business authority.

Business-domain SoD remains authoritative in Finance, HR, Procurement and other specialist domains.

---

## Exceptions, escalation and service levels

### `Escalation_Classes`
Defines five escalation levels from routine local IT handling to critical operations/executive and serious security escalation.

### `Exception_Escalation_Framework`
Defines static exception types such as critical outage, failed high-risk change, backup/recovery failure, unsupported technology, access-control exception, production technology disruption and suspected data-integrity issue.

### `Service_Level_Framework`
Defines synthetic internal service objectives for acknowledgement, provisioning, restoration initiation and service updates.

These targets are internal fictional HAV Seafood assumptions. They are not contractual SLA commitments, legal requirements or external benchmarks.

---

## IT process framework

### `IT_Process_Definitions`
Defines 24 recurring IT processes covering:

- incident/service management;
- problem management;
- standard/privileged/access lifecycle;
- normal/standard/emergency change;
- endpoint lifecycle;
- patching/security updates;
- backup/recovery;
- security response;
- vendor access;
- integration failure;
- critical technology outage.

### `IT_Process_Steps`
Contains 120 ordered static process steps. These are process design records, not operational workflow history.

### `System_Process_Mapping`
Maps all 13 existing enterprise systems to the applicable IT governance processes.

---

## Cross-domain ownership principle

The central rule is:

> **IT owns the technology process; the owning business domain owns the business decision and business data.**

Examples:

- IT restores ERP; Finance decides financial/accounting treatment.
- IT supports Online Banking technical access; Finance controls payment authority.
- IT restores MES/network technology; Production decides operational priorities.
- IT restores QMS/cold-chain technology; Quality determines food-safety/product consequences.
- IT provisions approved access; the business/data owner approves the underlying business need.
- IT contains a technical data-integrity propagation issue; the authoritative business owner validates business correctness.

Technical administrator privilege must never be interpreted as business approval authority.

---

## Relationship with earlier IT architecture

### Systems, Applications & Integration
`hav_seafood_it_systems_applications_integration_architecture_v1.xlsx` remains authoritative for technical system profiles, integrations, environments, dependencies, support model and maintenance windows.

### Identity, Access & Information Security
`hav_seafood_it_identity_access_security_framework_v1.xlsx` remains authoritative for identity types, account classes, access profiles, system access roles, authentication, JML rules, security classifications and security requirements.

### Infrastructure, Endpoints & Continuity
`hav_seafood_it_infrastructure_endpoint_continuity_v1.xlsx` remains authoritative for IT assets, network zones, infrastructure services, backup profiles, recovery tiers, continuity requirements, patch/lifecycle profiles and monitoring requirements.

This workbook provides the process and governance layer around those structures.

---

## Phase 1 exclusions

This workbook contains no:

- help-desk tickets;
- service-request cases;
- incident records or comments;
- actual incident priorities;
- outage timestamps;
- actual problems or root-cause analyses;
- known-error records;
- change requests;
- deployments;
- rollback events;
- emergency-change events;
- change approvals;
- maintenance execution records;
- patch executions;
- vendor support tickets;
- security incidents;
- phishing reports;
- malware/security alerts;
- access-provisioning events;
- backup failures;
- restore executions;
- monitoring alerts;
- actual control executions;
- control failures;
- audit findings;
- exception cases;
- SLA/KPI results;
- operational IT emails or communications.

These belong to Phase 3 after the Phase 2 stories are deliberately designed.

---

## Story neutrality

The architecture does not deliberately seed outcomes such as recurring outages, failed changes, weak access removal, security incidents, backup failures, vendor deterioration, chronic support delays, unsupported technology or control bypasses.

Those patterns should be selected in Phase 2 and introduced deliberately in Phase 3 operational data.

---

## Recommended AI use

For fast navigation:

- What IT services exist? -> `IT_Service_Catalog`
- What does a service depend on? -> `Service_Dependencies`
- What request type should be used? -> `Request_Types`
- How should an incident be classified? -> `Incident_Categories` + `Impact_Urgency_Matrix`
- What priority rules apply? -> `Incident_Priority_Framework`
- What incident transitions are allowed? -> `Incident_Lifecycle`
- When should repeated incidents become a problem? -> `Problem_Framework`
- What change class/risk applies? -> `Change_Types` + `Change_Risk_Classification`
- Who must approve a change? -> `Change_Approval_Rules` + `Position_Authority`
- What IT controls exist? -> `IT_Control_Framework`
- Which SoD rules apply? -> `IT_Segregation_of_Duties`
- How should an exception escalate? -> `Exception_Escalation_Framework` + `Escalation_Classes`
- What service targets exist? -> `Service_Level_Framework`
- How is an IT process designed? -> `IT_Process_Definitions` + `IT_Process_Steps`
- Which processes apply to a system? -> `System_Process_Mapping`
- Where does IT responsibility stop? -> `Cross_Domain_Interfaces` + `Source_Precedence`

---

## Overall role of this architecture

Together, these sheets form HAV Seafood's **static IT service-management, change-governance and control layer**.

They connect the existing system, identity/security and infrastructure architectures to realistic internal support services, incident/problem structures, change governance, controls, escalation and process design while preserving the authoritative boundaries of HR, Finance, Production, Quality, Procurement, Sales, Marketing, Logistics and Shared Enterprise.

This completes the core IT architecture needed before Phase 2 story design and later generation of realistic IT tickets, change records, alerts, outage logs, support communications, vendor cases, control evidence and service-performance data.
