ISO/IEC 27001 — Information Security Management

ISO/IEC 27001:2022 (Information security, cybersecurity and privacy protection — Information security management systems — Requirements) defines the requirements for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS). It is the most widely adopted information security standard globally and serves as the basis for ISMS certification.

In the context of NexoGraph, ISO/IEC 27001 is relevant both as a product requirement driver (automotive OEMs and tier-1 suppliers are often required to certify their development environments) and as a source of security requirements that must be captured and traced in the requirements model.

ISMS Structure

ISO/IEC 27001 follows the ISO High Level Structure (HLS), the same Annex SL/SL framework used by ISO 9001 and ISO 14001:

The PDCA (Plan-Do-Check-Act) cycle runs continuously: risks evolve, controls are tested, gaps are closed.

Risk-Based Approach

The core of ISO/IEC 27001 is a risk register driven by asset-based analysis:

Step	Description	NexoGraph
Asset identification	Identify information assets (data, systems, processes)	Gap — no Asset entity type
Threat and vulnerability assessment	Identify what could go wrong with each asset	Gap — no Threat entity type
Risk assessment	Likelihood × impact → risk level	Gap — no Risk entity type
Risk treatment	Choose control(s) to reduce, accept, transfer, or avoid each risk	`Requirement` (reqCat: SECURITY) documents treatment decisions
Statement of Applicability (SoA)	Document which controls from Annex A apply and why	Gap — no SoA artefact entity
Residual risk acceptance	Formally accept remaining risk	Gap — no risk acceptance record

Annex A Controls

ISO/IEC 27001:2022 Annex A lists 93 controls organized in four themes, each of which generates security requirements that must be implemented and evidenced:

Theme	Controls	Example areas
Organizational (A.5)	37 controls	Information security policies, roles, asset management, supplier relationships, incident management
People (A.6)	8 controls	Screening, terms and conditions, awareness training, remote working
Physical (A.7)	14 controls	Physical access, physical security perimeter, clear desk/screen policy
Technological (A.8)	34 controls	Access control, cryptography, secure development, vulnerability management, logging and monitoring

Each applicable control generates at least one security requirement (often several) that must be implemented and verified.

NexoGraph Alignment

ISO/IEC 27001 concept	NexoGraph implementation
Interested party (internal/external stakeholder)	`Stakeholder` — role, organization, category fields
Regulatory body / auditor	`Stakeholder` (category: REGULATORY)
Customer with security obligations	`Stakeholder` (category: CUSTOMER)
ISMS scope	`Package` — top-level package defines system scope
Security requirement (control implementation)	`Requirement` (reqCat: SECURITY)
Control rationale	`rationale` field on Requirement
Control source (Annex A reference)	`source` field on Requirement (e.g., "A.8.7 — Malware protection")
Priority of implementation	`priority` field on Requirement
Requirement lifecycle (draft → certified)	Lifecycle service governs approval and re-assessment gates
Business context for ISMS	`BusinessCase` — captures business objectives and information security strategy

Practical Usage in NexoGraph

A NexoGraph project representing an ISMS scope can be structured as follows:

Package: ISMS Scope (STAKEHOLDER_REQUIREMENTS root)
├── Package: A.5 — Organizational controls
│   ├── Requirement: A.5.1 — Information security policies documented and approved
│   ├── Requirement: A.5.9 — Inventory of information assets maintained
│   └── ...
├── Package: A.6 — People controls
├── Package: A.7 — Physical controls
└── Package: A.8 — Technological controls
    ├── Requirement: A.8.7 — Anti-malware deployed and monitored
    ├── Requirement: A.8.24 — Cryptographic algorithms approved per policy
    └── ...

Stakeholders (asset owners, CISO, auditor) link to the relevant requirement packages via reference relations, enabling per-stakeholder requirement coverage views.

Gap Analysis

Gap	ISO/IEC 27001 clause	Status
Asset inventory entity	§6.1.2	Not modelled — no Asset entity type
Risk register	§6.1.2	Not modelled — no Risk entity type
Statement of Applicability (SoA)	§6.1.3	Not modelled — the SoA is a document with yes/no per control; could be approximated with Package + tags
Control effectiveness (audit evidence)	§9.1	Not modelled — evidence/finding artefacts are planned
Nonconformity tracking	§10.1	Not modelled
Annex A control reference field	—	Partial — `source` field can carry control identifier but is unstructured

Relationship to IEC 62443 and ISO/SAE 21434

Standard	Layer	ISMS intersection
ISO/IEC 27001	Organization-level ISMS (IT and corporate)	Parent management system; defines the security policy all other standards operate under
IEC 62443	OT/IACS systems within the organization	Operational technology controls complement 27001 IT controls
ISO/SAE 21434	Vehicle product cybersecurity	CSMS (Cybersecurity Management System) is analogous to an ISMS scoped to the vehicle product lifecycle

Auditors commonly expect a 27001-certified ISMS to envelope the CSMS (21434) and the IACS security program (62443), with cross-references between the Statement of Applicability and the domain-specific requirement sets.