ISO 27001:2022 — OVERVIEW

OWNER: julian
UPDATED: 2026-03-24
SCOPE: GE internal ISMS, all client projects requiring certification
STANDARD: ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements

---

WHAT_IS_ISO_27001

ISO 27001 is the international standard for Information Security Management Systems (ISMS).
It does NOT prescribe specific technical controls.
It prescribes a MANAGEMENT SYSTEM — a structured approach to managing information security risks.

RULE: ISO 27001 certification applies to a DEFINED SCOPE — not necessarily the entire organization.
GE's ISMS scope: "Design, development, and delivery of custom SaaS applications using AI-driven multi-agent software development, including supporting infrastructure and client data processing."

The 2022 revision:
- Reduced Annex A controls from 114 to 93 (merged, reorganized)
- Added 11 new controls (threat intelligence, cloud security, secure coding, etc.)
- Restructured into 4 themes instead of 14 domains
- Aligned with ISO 27002:2022 guidance

---

CLAUSES_4_TO_10 — MANAGEMENT_SYSTEM_REQUIREMENTS

CLAUSE_4: CONTEXT_OF_THE_ORGANIZATION

PURPOSE: understand who you are, what you do, and who cares about your security.

4.1 — Understanding the organization and its context
REQUIRES: identify external and internal issues relevant to ISMS purpose
GE_EXAMPLE: external = EU regulatory landscape (GDPR, AI Act, NIS2), client security expectations, threat landscape. Internal = multi-agent architecture, AI-driven development, remote-first operation.
CHECK: documented context analysis reviewed at least annually

4.2 — Understanding needs and expectations of interested parties
REQUIRES: identify stakeholders and their security requirements
GE_STAKEHOLDERS:
- Clients (enterprise SMEs) → expect ISO 27001 cert, SOC 2 report, GDPR compliance
- Autoriteit Persoonsgegevens → GDPR compliance
- Employees/agents → secure working environment, clear policies
- Cloud providers (Hetzner, k3s) → shared responsibility model
- End users of client products → data protection, availability
CHECK: stakeholder register maintained and reviewed annually

4.3 — Determining the scope of the ISMS
RULE: scope MUST be documented and available to interested parties
RULE: scope boundaries must be clearly defined — what is IN, what is OUT
GE_SCOPE: all systems, people (human + AI agents), processes, and infrastructure involved in software delivery
CHECK: scope statement published, reviewed when context changes

4.4 — Information security management system
REQUIRES: establish, implement, maintain, and continually improve the ISMS
IF scope or context changes THEN reassess ISMS boundaries

CLAUSE_5: LEADERSHIP

PURPOSE: top management commitment is NOT optional. Auditors check this first.

5.1 — Leadership and commitment
REQUIRES: top management (Dirk-Jan) demonstrates commitment by:
- Ensuring security policy and objectives are established
- Ensuring ISMS integration into business processes
- Ensuring resources are available
- Communicating the importance of security
- Ensuring ISMS achieves intended outcomes
- Directing and supporting people
CHECK: evidence of management involvement — meeting minutes, resource allocation decisions, policy sign-off

5.2 — Policy
REQUIRES: documented information security policy that:
- Is appropriate to GE's purpose
- Includes security objectives or framework for setting them
- Includes commitment to satisfy applicable requirements
- Includes commitment to continual improvement
- Is available as documented information
- Is communicated within the organization
- Is available to interested parties as appropriate
GE_IMPLEMENTATION: constitution.md + security policy published on wiki
CHECK: policy dated, signed by management, reviewed annually

5.3 — Organizational roles, responsibilities, and authorities
REQUIRES: assign and communicate ISMS roles
GE_MAPPING:
- ISMS Manager: julian (Compliance Officer)
- Internal Auditor: amber (Participation Auditor)
- Risk Owner: varies by asset (agent owners)
- Security Operations: victoria
- Incident Commander: mira
CHECK: RACI matrix documented, no orphaned responsibilities

CLAUSE_6: PLANNING

PURPOSE: risk-based thinking — the HEART of ISO 27001.

6.1 — Actions to address risks and opportunities
6.1.1 — General: determine risks and opportunities considering context (clause 4)
6.1.2 — Information security risk assessment
REQUIRES:
- Defined risk assessment methodology (criteria, likelihood, impact, risk acceptance)
- Risk assessment process that is repeatable and produces consistent results
- Risk identification for confidentiality, integrity, availability loss
- Risk analysis (assign likelihood and impact values)
- Risk evaluation (compare against acceptance criteria, prioritize)
GE_METHOD: asset-based risk assessment. Assets = systems, data, processes. Threats = per threat intelligence (A.5.7). Vulnerabilities = from scanning + review.
RULE: risk assessment MUST be performed at planned intervals AND when significant changes occur
CHECK: risk register maintained, dated, with risk owners assigned

6.1.3 — Information security risk treatment
REQUIRES:
- Select appropriate risk treatment options (mitigate, accept, avoid, transfer)
- Determine all controls necessary (not limited to Annex A)
- Compare selected controls to Annex A to verify nothing overlooked
- Produce a Statement of Applicability (SoA)
- Formulate a risk treatment plan
- Obtain risk owner approval for residual risks
RULE: Statement of Applicability is THE most important document for certification
SoA MUST contain: every Annex A control, justification for inclusion/exclusion, implementation status

6.2 — Information security objectives
REQUIRES: measurable security objectives at relevant functions and levels
GE_OBJECTIVES:
- Zero critical vulnerabilities in production > 48 hours
- 100% secret rotation within policy period
- Incident response time < 1 hour for P1
- 100% agent compliance with constitution
- Annual penetration test with remediation < 30 days
CHECK: objectives documented, measurable, monitored, communicated

6.3 — Planning of changes
REQUIRES: changes to ISMS carried out in a planned manner
GE_IMPLEMENTATION: change management via marta (GitHub Goalkeeper) + alex/tjitte (CI/CD)

CLAUSE_7: SUPPORT

PURPOSE: provide resources, competence, awareness, communication, and documentation.

7.1 — Resources
REQUIRES: determine and provide resources needed for ISMS
GE_CONTEXT: AI agents are resources — their availability, capability, and configuration are ISMS resources

7.2 — Competence
REQUIRES: determine necessary competence, ensure people (and agents) are competent
GE_IMPLEMENTATION: agent profiling ensures each agent has correct domain knowledge. AGENT-REGISTRY.json tracks capabilities.
CHECK: competence records maintained (agent profiles, training logs)

7.3 — Awareness
REQUIRES: people aware of security policy, their contribution, implications of nonconformity
GE_IMPLEMENTATION: constitution.md injected at agent boot = mandatory awareness. JIT learnings = continuous education.

7.4 — Communication
REQUIRES: determine internal and external communication needs (what, when, with whom, who, how)
GE_IMPLEMENTATION: Redis Streams for internal. Admin-UI for management. Wiki for documentation.

7.5 — Documented information
REQUIRES: ISMS documentation created, updated, controlled
7.5.1 — The ISMS shall include documented information required by the standard + determined by GE as necessary
7.5.2 — Creating and updating: appropriate identification, format, review and approval
7.5.3 — Control: available when needed, adequately protected, distribution/access/retrieval/use controlled, storage/preservation, change control, retention and disposition
GE_IMPLEMENTATION: wiki (MkDocs) = controlled documentation. Git = version control. PostgreSQL = SSOT.
CHECK: document control procedure exists, version history maintained

CLAUSE_8: OPERATION

PURPOSE: execute the plans from clause 6.

8.1 — Operational planning and control
REQUIRES: plan, implement, and control processes to meet requirements
INCLUDES: managing outsourced processes (cloud providers, LLM API providers)

8.2 — Information security risk assessment
REQUIRES: perform risk assessments at planned intervals or when significant changes occur
GE_SCHEDULE: quarterly risk assessment, ad-hoc for significant changes
CHECK: risk assessment reports dated, approved by risk owners

8.3 — Information security risk treatment
REQUIRES: implement the risk treatment plan
CHECK: treatment plan execution tracked, residual risks documented and accepted

CLAUSE_9: PERFORMANCE_EVALUATION

PURPOSE: measure, monitor, analyze, evaluate, audit, and review.

9.1 — Monitoring, measurement, analysis, and evaluation
REQUIRES: determine what to monitor/measure, methods, when, who analyzes
GE_METRICS:
- Vulnerability scan results (trivy, semgrep) → weekly
- Access review completion → quarterly
- Incident count and resolution time → monthly
- Agent compliance scores → continuous
- Secret rotation compliance → monthly
CHECK: monitoring results documented and reported to management

9.2 — Internal audit
REQUIRES: conduct internal audits at planned intervals
9.2.1 — Audit programme considering importance of processes and previous audits
9.2.2 — For each audit: define criteria and scope, select auditors (objective, impartial), ensure results reported to management
GE_IMPLEMENTATION: amber conducts internal audits per annual audit programme
RULE: auditor independence — amber MUST NOT audit own work
CHECK: audit programme documented, audit reports complete, findings tracked
SEE_ALSO: audit-procedures.md for full methodology

9.3 — Management review
REQUIRES: top management reviews ISMS at planned intervals
INPUTS: status of previous actions, changes in context, security performance, audit results, risk assessment, opportunities for improvement
OUTPUTS: decisions on improvement opportunities, changes to ISMS, resource needs
GE_SCHEDULE: quarterly management review
CHECK: management review minutes documented with decisions and action items

CLAUSE_10: IMPROVEMENT

PURPOSE: correct nonconformities and continually improve.

10.1 — Continual improvement
REQUIRES: continually improve suitability, adequacy, and effectiveness of ISMS
GE_IMPLEMENTATION: wiki brain captures learnings. Knowledge synthesizer detects patterns. Evolution entries track improvements.

10.2 — Nonconformity and corrective action
REQUIRES: when nonconformity occurs:
- React (control, correct, deal with consequences)
- Evaluate need for action to eliminate cause
- Implement corrective action
- Review effectiveness
- Make changes to ISMS if necessary
RULE: corrective actions MUST be proportionate to the effects of nonconformities
CHECK: nonconformity log maintained, corrective actions tracked to closure

---

PDCA_CYCLE

ISO 27001 is built on the Plan-Do-Check-Act cycle.

PLAN (clauses 4-6): establish ISMS policy, objectives, processes, and procedures
- Context analysis → risk assessment → risk treatment → SoA → objectives
DO (clauses 7-8): implement and operate
- Deploy controls, train people, operate processes
CHECK (clause 9): monitor and review
- Internal audit, management review, measure effectiveness
ACT (clause 10): maintain and improve
- Corrective actions, continual improvement

RULE: the cycle is CONTINUOUS — not a one-time project
GE_ADVANTAGE: AI agents operate in continuous loops naturally. Evidence generation is a byproduct of normal operations.

---

CERTIFICATION_PROCESS

STAGE_1_AUDIT (documentation review)

DURATION: typically 1-2 days on-site or remote
AUDITOR_CHECKS:
- ISMS scope defined and documented
- Information security policy exists
- Risk assessment methodology defined
- Risk assessment performed, risk treatment plan exists
- Statement of Applicability complete
- Internal audit performed
- Management review performed
- Mandatory documented information exists
OUTCOME: readiness assessment. Identifies gaps before Stage 2.
TYPICAL_GAP: missing SoA, incomplete risk assessment, no management review minutes

STAGE_2_AUDIT (implementation audit)

DURATION: typically 3-5 days depending on scope complexity
TIMING: must be within 6 months of Stage 1
AUDITOR_CHECKS:
- Controls actually implemented (not just documented)
- People aware of their responsibilities
- ISMS processes operating effectively
- Risk treatment plan implemented
- Monitoring and measurement happening
- Internal audit and management review effective
- Continual improvement evident
SAMPLING: auditors sample controls — they do NOT check everything
OUTCOME: certification decision. May include nonconformities.

IF major nonconformity THEN certification withheld until resolved (typically 90 days)
IF minor nonconformity THEN certification granted, resolve by next surveillance
IF observation THEN noted for improvement, no action required

SURVEILLANCE_AUDITS

FREQUENCY: annually (year 1 and year 2 after certification)
SCOPE: subset of ISMS — auditors choose based on risk and previous findings
CHECK: continual improvement demonstrated, nonconformities from previous audits resolved

RECERTIFICATION_AUDIT

FREQUENCY: every 3 years (full cycle restart)
SCOPE: entire ISMS
TIMING: must be completed before certificate expires

---

STATEMENT_OF_APPLICABILITY (SoA)

The SoA is the SINGLE MOST IMPORTANT document in ISO 27001.

CONTENT: for every Annex A control (all 93):
- Control reference and title
- Applicability: YES or NO
- Justification for inclusion or exclusion
- Implementation status: fully implemented / partially implemented / planned / not implemented
- How it is implemented (brief description)
- Evidence reference

RULE: you CANNOT exclude a control simply because it is "difficult" or "expensive"
RULE: exclusion MUST be justified based on risk assessment — "risk assessment shows this risk is not applicable because..."
COMMON_VALID_EXCLUSIONS for software agency:
- A.7.3 (securing offices) — IF fully remote with no physical office THEN can exclude with justification
- A.7.4 (physical security monitoring) — same condition
NOTE: even "excluded" controls should be briefly justified in SoA

CHECK: SoA version controlled, dated, approved by ISMS manager
CHECK: SoA consistent with risk assessment and risk treatment plan
CHECK: SoA updated when controls change

---

WHAT_AUDITORS_ACTUALLY_LOOK_FOR

TOP_AUDIT_FINDINGS (industry-wide)

1. Risk assessment not connected to control selection — SoA controls chosen from a template, not from actual risk assessment
2. No evidence of management involvement — policy signed but management cannot explain ISMS
3. Internal audit is a checkbox exercise — no real findings, no improvement
4. Monitoring exists but nobody reviews results — dashboards built, never checked
5. Corrective actions not followed through — findings logged but never closed
6. Documented procedures not followed — policy says one thing, reality is different
7. Competence not demonstrated — people assigned roles without evidence of capability
8. Third-party risk not managed — cloud providers used without security assessment

WHAT_MAKES_AUDITORS_HAPPY

• Management can articulate security risks in business terms
• Risk register is alive (updated, discussed, acted upon)
• Internal audits found real issues (means the programme works)
• Corrective actions show root cause analysis (not just symptom fixing)
• Evidence is readily available (not scrambled together)
• People know their roles and can explain what they do
• Continual improvement is genuine (not fabricated for audit)

GE_ADVANTAGES

• Agent operations produce evidence automatically (git commits, deployment logs, scan results)
• Constitution enforces consistent behavior (awareness built in)
• Wiki brain captures institutional knowledge (documented information)
• Automated scanning (trivy, semgrep, kube-bench) = continuous monitoring
• AGENT-REGISTRY.json = competence register
• Redis Streams = auditable communication trail

GE_RISKS

• AI agents as "personnel" — auditors may question competence and awareness for non-human workers
• Rapid change velocity — change management must keep pace
• Multi-model dependency (Claude, OpenAI, Gemini) — third-party risk management critical
• k3s single-node — availability and resilience questions

---

MANDATORY_DOCUMENTED_INFORMATION

The standard explicitly requires these documents (minimum):

POLICIES_AND_SCOPE:
- ISMS scope (4.3)
- Information security policy (5.2)

RISK:
- Risk assessment process (6.1.2)
- Risk treatment process (6.1.3)
- Statement of Applicability (6.1.3d)
- Risk assessment results (8.2)
- Risk treatment results (8.3)

OPERATIONS:
- Security objectives (6.2)
- Competence evidence (7.2)
- Operational planning documentation (8.1)

MONITORING:
- Monitoring and measurement results (9.1)
- Internal audit programme and results (9.2)
- Management review results (9.3)
- Nonconformities and corrective actions (10.2)

PLUS: any documented information the organization determines is necessary for ISMS effectiveness.

GE_DOCUMENTATION_MAP:
- Wiki → policies, procedures, standards
- PostgreSQL → operational data, agent registry, task history
- Git → change history, code reviews, deployments
- Redis Streams → communication audit trail
- File system → scan results, audit reports (archived)

---

INTEGRATION_WITH_OTHER_STANDARDS

ISO 27001 uses the Harmonized Structure (Annex SL), making it compatible with:
- ISO 9001 (quality) — shared management system structure
- ISO 27701 (privacy) — extends ISMS to privacy information management
- ISO 22301 (business continuity) — BCM integration

SOC 2 MAPPING:
- CC1 (Control Environment) ≈ Clauses 5, 7
- CC2 (Communication) ≈ Clause 7.4
- CC3 (Risk Assessment) ≈ Clause 6.1
- CC4 (Monitoring) ≈ Clause 9.1
- CC5 (Control Activities) ≈ Clause 8, Annex A
- CC6 (Logical Access) ≈ A.5.15-A.5.18, A.8.2-A.8.5
- CC7 (System Operations) ≈ A.8.15-A.8.16, A.5.24-A.5.28
- CC8 (Change Management) ≈ A.8.32-A.8.33
- CC9 (Risk Mitigation) ≈ Clause 6.1.3

RULE: maintain ONE integrated management system, not separate silos
GE_APPROACH: single wiki-based ISMS with cross-references to SOC 2, GDPR, CSA STAR mappings

---

SEE_ALSO: iso27001-annex-a.md, iso27001-evidence-map.md, soc2-trust-criteria.md, compliance-automation.md
READ_ALSO: domains/security/index.md, domains/eu-regulation/index.md