# HAV Seafood — Identity, Access & Information Security Framework

## Purpose

This workbook defines the static **Identity, Access & Information Security Framework** for HAV Seafood.

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

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

The framework defines how digital identities, account classes, authentication, system access roles, role-based access profiles, privileged access, joiner/mover/leaver controls, access approvals/reviews, segregation of duties, information classification and security-control requirements are designed.

It intentionally contains **no actual user accounts, permission grants, access requests, sign-ins, MFA enrollments, password changes, security alerts, access-review results or security incidents**.

---

## Architecture scope at a glance

The workbook contains:

- **7 identity types**;
- **8 account classes**;
- **9 authentication profiles**;
- **70 structural system access roles** across the existing **13 `ESYS-*` enterprise systems**;
- **34 reusable role-based access profiles**;
- **222 access-profile-to-system-role relationships**;
- access defaults for all **56 authoritative enterprise job roles**;
- **11 privileged-access classes/rules**;
- **15 joiner/mover/leaver lifecycle rules**;
- **13 access approval/review rules**;
- **16 access segregation-of-duties rules**;
- **4 information-security classifications**;
- security classification mappings for all **132 existing `DOBJ-*` governed data objects**;
- **22 static security-control requirements**.

The framework is deliberately proportionate to HAV Seafood's size. It creates enough structure for realistic later operational data without attempting to model enterprise-scale IAM complexity.

---

## Core model

The principal identity/access relationship is:

`HR Person / External Subject / Non-human Subject`

`-> Digital Identity Type`

`-> Account Class`

`-> Authentication Profile`

`-> Access Profile`

`-> System Access Role`

`-> Future Permission Grant`

Role-based eligibility follows:

`HR Job Role -> HR Position -> IT Access Profile -> System Access Roles`

The framework deliberately separates **eligibility** from **actual access**.

A job role may make a person normally eligible for an access profile, but an actual account/role assignment belongs to Phase 3 and may require additional business-owner or privileged approval.

---

## Important conceptual boundaries

`Employee != Digital Identity`

`Digital Identity != Account`

`Account != Access Profile`

`Access Profile != System Access Role`

`System Access Role != Permission Grant`

`Eligibility != Access`

`Approval Rule != Approval Event`

`Privileged Eligibility != Privileged Account`

`Technical Administrator != Business Approver`

`Information Classification != Business Ownership`

`Security Control Requirement != Control Execution`

These distinctions should be preserved in later operational datasets.

---

## Workbook contents

### `Identity_Types`

Defines human and non-human identity categories, including employee, privileged, external support, service/integration, controlled shared operational, device and emergency identities.

Named identities are the default for interactive use. Shared operational identities are treated as controlled exceptions rather than normal design.

### `Account_Classes`

Defines reusable account classes and their normal authentication, privilege, expiry, ownership and review expectations.

### `Authentication_Framework`

Defines the static authentication models used by the framework, including standard federated MFA, frontline named access, separate privileged authentication, external temporary access, service credentials, device identities, emergency access and bank-managed strong authentication.

No credentials or authentication events are stored.

### `System_Access_Roles`

Defines 70 structural roles across the 13 existing systems.

Roles distinguish business use, read-only access, operational execution, approval capability, technical administration, security administration and reporting/analytics.

Technical administrator roles explicitly do **not** confer business transaction authority.

### `Access_Profiles`

Defines 34 reusable access profiles aligned to HAV Seafood's actual organizational roles, including Production, Logistics, Quality, Maintenance, Sanitation, Procurement, Sales, Marketing, Finance, HR, IT and Executive profiles.

### `Profile_System_Roles`

Maps access profiles to structural system roles.

The mapping distinguishes:

- required role components;
- default provisioning eligibility;
- roles requiring separate approval;
- roles requiring business-owner approval.

Sensitive and privileged role components are deliberately not treated as automatic simply because they are relevant to a job profile.

### `Role_Position_Access_Defaults`

Provides one current architecture access default for each of the 56 authoritative enterprise job roles.

The workbook reuses HR `Role_ID` and `Position_ID` values. It does not assign access to named employees.

### `Privileged_Access_Framework`

Defines privileged technical access classes, eligible positions, approval expectations, account separation and review frequency.

The design emphasizes that:

> technical access to administer a platform is separate from authority to approve the business activity performed in that platform.

### `Joiner_Mover_Leaver_Rules`

Defines static access-lifecycle rules triggered by authoritative HR employment/role changes and external-support lifecycle events.

No joiner, mover or leaver events are contained in the workbook.

### `Access_Approval_Review`

Defines required approval and review structures for standard, sensitive, privileged, external, service and emergency access.

Business owners decide business need. IT provisions and technically administers access.

### `Access_Segregation_Rules`

Defines IT-access interpretations of cross-domain segregation requirements.

Where a business control originates in Finance, HR, Quality, Sales or another domain, that domain remains authoritative for the business meaning. IT defines how technical access should preserve or support the control.

### `Information_Classification`

Defines four internal information-security classes:

1. `ISC-01 Public`
2. `ISC-02 Internal`
3. `ISC-03 Confidential`
4. `ISC-04 Restricted`

These are synthetic HAV Seafood internal security classifications, not statements of statutory classification requirements.

### `System_Security_Requirements`

Maps the existing 13 enterprise systems to their maximum information classification, authentication posture and core security expectations.

The existing technical system authentication design from the IT Systems, Applications & Integration Architecture is reused rather than redefined.

### `Data_Security_Mapping`

Classifies all 132 existing governed `DOBJ-*` data objects while preserving their upstream business-owner and authoritative-system assignments.

Classification does **not** transfer business ownership to IT.

### `Security_Control_Requirements`

Defines 22 static security requirements covering identity, least privilege, MFA, privileged access, lifecycle control, external access, logging, encryption, restricted repositories, managed devices, SoD and credential handling.

These are control requirements, not evidence that a control was executed successfully.

### `Source_Precedence`

Documents authoritative source boundaries and prevents this workbook from overriding Shared Enterprise, HR, Finance or other business-domain architecture.

### `Architecture_Notes`

Records the most important architecture assumptions and boundaries.

### `Data_Dictionary`

Provides field-level definitions for the complete workbook.

---

## Relationship with HR & Organization Architecture

HR remains authoritative for:

- employees;
- employment status;
- job roles;
- positions;
- position seats;
- incumbency;
- management/reporting relationships.

IT uses these structures to define **normal access eligibility**.

The core relationship is:

`HR Role / Position -> IT Access Profile`

Actual employee accounts and grants are resolved later from current incumbency and approved provisioning events.

This prevents access architecture from becoming stale merely because employees move between positions.

---

## Relationship with Shared Enterprise Systems & Data Ownership

Shared Enterprise remains authoritative for:

- the 13 `ESYS-*` enterprise system identities;
- enterprise data-object identity;
- business data ownership;
- system-of-record assignments.

IT owns the identity/access/security design around those systems.

A critical rule is:

> **IT administration of a system does not make IT the business owner of the data stored in that system.**

The `Data_Security_Mapping` therefore carries upstream `Business_Owner_Domain_ID` and `Authoritative_System_ID` values alongside the IT security classification.

---

## Relationship with the IT Systems, Applications & Integration Architecture

The earlier IT architecture remains authoritative for technical system profiles, application components, environments and integration design.

This framework reuses its system-level authentication posture and extends it with:

- identity types;
- account classes;
- access roles;
- access profiles;
- privileged-access requirements;
- security classifications;
- security controls.

Detailed endpoints, network infrastructure, backup targets and continuity design remain for the later **IT Infrastructure, Endpoints & Continuity Architecture**.

---

## Cross-domain authority boundary

Access to a system is not the same as authority to make a business decision.

Examples:

- Finance owns payment and financial approval authority even when IT provisions the account;
- Quality owns release/disposition and technical-quality authority even when IT administers QMS;
- HR owns employment and employee-relations decisions even when IT can technically access People & Payroll;
- Sales owns commercial approval authority even when IT administers CRM;
- Marketing/Quality/Production retain their respective content and technical authority in Label Design & Printing.

The segregation rules in this workbook preserve these distinctions.

---

## Phase 1 exclusions

This workbook intentionally contains no operational or historical records such as:

- usernames;
- email addresses used as live account records;
- current system accounts;
- current permission grants;
- passwords;
- authentication secrets or keys;
- MFA registrations;
- login/sign-in records;
- failed authentication attempts;
- privileged sessions;
- access requests;
- access approvals;
- access provisioning events;
- role-assignment history;
- disabled-account history;
- password resets;
- access-review outcomes;
- SoD violations;
- security alerts;
- malware detections;
- vulnerability findings;
- phishing events;
- security incidents;
- investigation evidence;
- audit findings;
- control execution results.

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

---

## Story neutrality

The framework does not deliberately seed outcomes such as:

- excessive privilege;
- orphaned accounts;
- delayed leaver deactivation;
- unauthorized administrator access;
- weak MFA adoption;
- password sharing;
- segregation-of-duties failures;
- unauthorized Finance access;
- inappropriate HR access;
- vendor-access abuse;
- phishing compromise;
- malware;
- data leakage;
- failed access reviews;
- misuse of break-glass accounts.

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

---

## Recommended AI use

For fast context:

1. read this Markdown file;
2. use `Role_Position_Access_Defaults` to determine the normal access profile for a role;
3. use `Access_Profiles` + `Profile_System_Roles` to identify structural system access;
4. inspect `System_Access_Roles` for the capability boundary;
5. inspect `Access_Approval_Review` and `Access_Segregation_Rules` for control requirements;
6. use `Data_Security_Mapping` for the security classification of a governed data object;
7. use `Source_Precedence` before changing any shared entity or business ownership conclusion.

When generating Phase 3 data, actual employee access should be created from current HR incumbency plus the access/default/approval rules here — not by placing employee names directly into the architecture.

---

## Overall role of this architecture

Together, these structures form HAV Seafood's static **identity, authorization and information-security policy layer**.

They connect the existing workforce architecture to the existing system landscape and data-ownership model while preserving a strict distinction between technical access and business authority.

This gives later synthetic user accounts, access requests, sign-in logs, privileged activity, access reviews, provisioning events and security incidents a consistent foundation without embedding any operational history in Phase 1.
