ISO27001-Expert-1.5B

A bilingual (FR/EN) AI expert specialized in ISO/IEC 27001 Information Security Management Systems.

Model Description

ISO27001-Expert-1.5B is a QLoRA fine-tuned version of Qwen/Qwen2.5-1.5B-Instruct specialized in:

ISMS Implementation: Planning, scope definition, context of the organization, leadership commitment
Risk Management: Risk assessment methodologies, risk treatment, Statement of Applicability (SoA)
Security Controls (Annex A): All 93 controls across organizational, people, physical, and technological categories
Audit & Certification: Internal audits, certification process, surveillance audits, nonconformity management
Compliance Integration: Links with GDPR/RGPD, NIS2, DORA, SOC 2, and other frameworks
Continuous Improvement: Management review, corrective actions, performance evaluation

Training Details

Parameter	Value
Base Model	Qwen/Qwen2.5-1.5B-Instruct
Method	QLoRA (4-bit NF4, double quantization)
LoRA Rank	64
LoRA Alpha	128
Target Modules	q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj
Training Samples	1,383
Evaluation Samples	73
Epochs	3
Learning Rate	2e-4 (cosine schedule)
Batch Size	16 (4 x 4 gradient accumulation)
Max Sequence Length	1024

Usage

Basic Usage

from peft import PeftModel
from transformers import AutoModelForCausalLM, AutoTokenizer

# Load base model
base_model = AutoModelForCausalLM.from_pretrained(
    "Qwen/Qwen2.5-1.5B-Instruct",
    device_map="auto",
    torch_dtype="auto"
)

# Load fine-tuned adapter
model = PeftModel.from_pretrained(base_model, "AYI-NEDJIMI/ISO27001-Expert-1.5B")
tokenizer = AutoTokenizer.from_pretrained("AYI-NEDJIMI/ISO27001-Expert-1.5B")

# Chat
messages = [
    {"role": "system", "content": "You are ISO 27001 Expert, a specialized AI for information security management systems."},
    {"role": "user", "content": "Explain the key steps to implement an ISMS according to ISO 27001:2022"}
]

text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
inputs = tokenizer(text, return_tensors="pt").to(model.device)
outputs = model.generate(**inputs, max_new_tokens=512, temperature=0.7, top_p=0.9)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

Inference API

from huggingface_hub import InferenceClient

client = InferenceClient(token="YOUR_HF_TOKEN")

response = client.chat_completion(
    model="AYI-NEDJIMI/ISO27001-Expert-1.5B",
    messages=[
        {"role": "system", "content": "You are ISO 27001 Expert, a specialized AI for information security management systems."},
        {"role": "user", "content": "What are the requirements for Annex A 5.7 Threat Intelligence?"}
    ],
    max_tokens=500
)
print(response.choices[0].message.content)

Batch Processing for Audit Preparation

audit_questions = [
    "How to prepare for an ISO 27001 certification audit?",
    "What evidence is needed for control A.8.1 User endpoint devices?",
    "Explain the requirements for management review meetings"
]

for question in audit_questions:
    messages = [
        {"role": "system", "content": "You are ISO 27001 Expert."},
        {"role": "user", "content": question}
    ]
    text = tokenizer.apply_chat_template(messages, tokenize=False, add_generation_prompt=True)
    inputs = tokenizer(text, return_tensors="pt").to(model.device)
    outputs = model.generate(**inputs, max_new_tokens=400)
    print(f"\nQ: {question}")
    print(f"A: {tokenizer.decode(outputs[0], skip_special_tokens=True)}")
    print("-" * 80)

Example Outputs

Example 1: ISMS Implementation Roadmap

Input (EN):

What are the key steps to implement an ISO 27001 ISMS from scratch?

Output:

Implementing an ISO 27001 Information Security Management System (ISMS) follows a structured approach:

**Phase 1: Preparation (Months 1-2)**
1. **Obtain Leadership Commitment** (Clause 5):
   - Secure executive sponsorship and budget
   - Define information security policy
   - Assign roles and responsibilities (ISMS Manager, Information Security Officer)

2. **Define ISMS Scope** (Clause 4.3):
   - Identify business units, locations, processes covered
   - Consider dependencies and interfaces with external parties
   - Document exclusions with justification

3. **Understand Context** (Clause 4.1-4.2):
   - Internal context: Business objectives, culture, organizational structure
   - External context: Legal requirements, market conditions, stakeholder expectations
   - Identify interested parties: Customers, regulators, suppliers, employees

**Phase 2: Risk Assessment (Months 3-4)**
4. **Establish Risk Assessment Methodology** (Clause 6.1.2):
   - Define risk criteria: likelihood, impact scales (e.g., 1-5)
   - Risk acceptance criteria: What level of risk is acceptable?
   - Choose methodology: ISO 27005, NIST, qualitative vs. quantitative

5. **Identify Assets and Threats**:
   - Information assets: Databases, documents, intellectual property
   - Supporting assets: Hardware, software, personnel, facilities
   - Threats: Cyberattacks, human error, natural disasters, insider threats
   - Vulnerabilities: Unpatched systems, weak passwords, lack of encryption

6. **Assess and Evaluate Risks**:
   - Calculate inherent risk = Likelihood × Impact
   - Prioritize risks based on business criticality

**Phase 3: Risk Treatment (Months 5-6)**
7. **Select Risk Treatment Options** (Clause 6.1.3):
   - **Modify**: Implement security controls (most common)
   - **Retain**: Accept low risks within tolerance
   - **Avoid**: Eliminate risky activities
   - **Share**: Transfer via insurance or outsourcing

8. **Create Statement of Applicability (SoA)** (Clause 6.1.3d):
   - Review all 93 Annex A controls
   - For each control: Applicable (Yes/No), Implementation status, Justification
   - Add any additional controls specific to your organization

9. **Develop Risk Treatment Plan**:
   - Action items, owners, deadlines, resources needed
   - Track implementation progress

**Phase 4: Implementation (Months 7-10)**
10. **Implement Annex A Controls**:
    - Technical controls: Access control, encryption, network security
    - Organizational controls: Policies, procedures, training
    - Physical controls: Facility security, equipment protection
    - People controls: Background checks, security awareness

11. **Document ISMS Processes** (Clause 7.5):
    - Mandatory documents: Scope, policy, SoA, risk assessment, risk treatment plan
    - Operational procedures: Incident response, change management, backup
    - Records: Audit logs, training records, incident reports

12. **Deliver Security Awareness Training** (Clause 7.3):
    - General awareness for all employees
    - Role-specific training (IT, HR, management)
    - Ongoing training program

**Phase 5: Monitoring & Internal Audit (Months 11-12)**
13. **Monitor and Measure** (Clause 9.1):
    - Define KPIs: Number of incidents, patch compliance, training completion
    - Regular reviews of security metrics
    - Effectiveness of controls

14. **Conduct Internal Audits** (Clause 9.2):
    - Audit plan covering all ISMS areas
    - Trained internal auditors
    - Document findings and nonconformities

15. **Management Review** (Clause 9.3):
    - Senior leadership meeting (at least annually)
    - Review audit results, incidents, changes, improvement opportunities
    - Approve resources for corrective actions

**Phase 6: Certification (Month 13+)**
16. **Stage 1 Audit** (Document Review):
    - Certification body reviews ISMS documentation
    - Identifies gaps before Stage 2

17. **Stage 2 Audit** (On-Site Assessment):
    - Auditors verify control implementation
    - Interview staff, review evidence
    - May result in minor or major nonconformities

18. **Certification Decision**:
    - Address nonconformities within timeframe
    - Certificate issued (valid 3 years)
    - Annual surveillance audits required

**Ongoing: Continuous Improvement (Clause 10)**
- Corrective actions for nonconformities
- Preventive measures based on risk changes
- Adapt ISMS to new threats, technologies, regulations

Example 2: Annex A Controls - Access Control

Input (EN):

Explain ISO 27001 Annex A control 5.15 Access Control and how to implement it.

Output:

**ISO 27001:2022 Annex A 5.15 - Access Control**

**Control Statement**:
"Rules to control physical and logical access to information and other associated assets should be
established and implemented based on business and information security requirements."

**Purpose**:
Ensure only authorized individuals can access information assets, preventing unauthorized disclosure,
modification, or destruction.

**Implementation Guidance**:

**1. Access Control Policy**:
Develop a comprehensive policy covering:
- Default deny principle (access granted only when explicitly approved)
- Least privilege (minimum access necessary for job function)
- Separation of duties (no single person controls entire critical process)
- Access review frequency (quarterly/annually)
- Access revocation process (termination, role change)

**2. User Access Management (A.5.18)**:
- **Provisioning**:
  * Formal access request process (tickets, approvals)
  * Manager approval required
  * Role-based access control (RBAC) mapping

- **User Registration**:
  * Unique user IDs (no shared accounts except break-glass)
  * Strong password policy (complexity, length, expiration)
  * Multi-factor authentication (MFA) for privileged access

- **Deprovisioning**:
  * Immediate access revocation upon termination
  * Access review when changing roles
  * Automated offboarding workflows

**3. Physical Access Control** (A.7.2):
- Badge/biometric entry systems
- Visitor logging and escort procedures
- Server room access restricted to authorized personnel
- Security cameras in sensitive areas
- After-hours access monitoring

**4. Logical Access Control**:
- **Network Access**:
  * Firewall rules (deny all, allow by exception)
  * VPN for remote access with MFA
  * Network segmentation (VLANs, DMZ)

- **Operating System Access**:
  * Disable default/guest accounts
  * Administrator accounts used only for admin tasks
  * Privileged Access Management (PAM) solution

- **Application Access**:
  * Application-level authentication
  * Session timeout for inactivity
  * Single Sign-On (SSO) with centralized identity provider

- **Database Access**:
  * Database accounts separate from OS accounts
  * Encrypt sensitive data at rest
  * Audit logging of database access

**5. Access Rights Review (A.5.18)**:
- Quarterly review of all user access rights
- Annual review of privileged access
- Remove dormant accounts (inactive >90 days)
- Document review results and remediation

**6. Monitoring and Logging**:
- Log all access attempts (successful and failed)
- Alert on suspicious patterns: multiple failed logins, access outside business hours
- SIEM integration for correlation
- Retain logs per regulatory requirements (typically 1-7 years)

**Evidence for Auditors**:
- Access control policy and procedures
- RBAC matrix mapping roles to permissions
- Access request tickets and approval records
- Quarterly access review reports
- Termination/offboarding checklists
- SIEM logs showing access monitoring
- MFA enrollment statistics
- Password policy configuration screenshots

**Common Nonconformities**:
- Shared administrator accounts (violates unique IDs)
- No access reviews performed or documented
- Excessive privileges (users with more access than needed)
- No MFA on privileged accounts
- Terminated employees still have active accounts

**Integration with Other Controls**:
- A.5.16 Identity Management (foundation for access control)
- A.5.17 Authentication Information (password/credential management)
- A.5.18 Access Rights (detailed access management process)
- A.8.2 Privileged Access Rights (elevated permissions)

Example 3: Risk Assessment Methodology

Input (FR):

Comment réaliser une analyse de risques conforme à l'ISO 27001:2022 ?

Output:

L'analyse de risques selon l'ISO 27001:2022 (Clause 6.1.2) suit une méthodologie structurée :

**1. Définir le Contexte et les Critères de Risque**

**Critères de Vraisemblance** (Likelihood):
| Niveau | Description | Fréquence |
|--------|-------------|-----------|
| 1 - Très faible | Presque impossible | < 1 fois / 10 ans |
| 2 - Faible | Peu probable | 1 fois / 5-10 ans |
| 3 - Moyen | Possible | 1 fois / 1-5 ans |
| 4 - Élevé | Probable | 1 fois / an |
| 5 - Très élevé | Quasi certain | Plusieurs fois / an |

**Critères d'Impact**:
| Niveau | Financier | Réputation | Légal/Réglementaire |
|--------|-----------|------------|---------------------|
| 1 - Négligeable | < 10K€ | Impact local | Pas d'impact |
| 2 - Faible | 10-50K€ | Médias locaux | Avertissement |
| 3 - Moyen | 50-250K€ | Médias nationaux | Amende modérée |
| 4 - Élevé | 250K-1M€ | Perte clients importants | Sanction importante |
| 5 - Critique | > 1M€ | Faillite possible | Poursuites pénales |

**Matrice de Risque**:
- Risque = Vraisemblance × Impact
- Scores 1-8 : Faible (vert) - Accepter
- Scores 9-15 : Moyen (orange) - Traiter selon priorité
- Scores 16-25 : Élevé (rouge) - Traiter immédiatement

**2. Identifier les Actifs**

**Actifs Informationnels Primaires**:
- Bases de données clients (noms, adresses, données bancaires)
- Propriété intellectuelle (brevets, code source, formules)
- Documents financiers (bilans, contrats, factures)
- Données RH (salaires, évaluations, dossiers médicaux)

**Actifs de Support**:
- Matériel : Serveurs, postes de travail, équipements réseau
- Logiciels : Applications métier, OS, bases de données
- Personnel : Compétences clés, connaissances métier
- Infrastructures : Locaux, électricité, climatisation

**Classification des Actifs** (C-I-D):
- **Confidentialité** : Public, Interne, Confidentiel, Secret
- **Intégrité** : Faible, Normale, Élevée, Critique
- **Disponibilité** : RTO (Recovery Time Objective) acceptable

**3. Identifier Menaces et Vulnérabilités**

**Menaces Courantes**:
- **Cybercriminels** : Ransomware, phishing, APT
- **Erreur humaine** : Mauvaise configuration, suppression accidentelle
- **Défaillance technique** : Panne matérielle, bug logiciel
- **Catastrophes naturelles** : Inondation, incendie, tremblement de terre
- **Menaces internes** : Employé malveillant, négligence

**Vulnérabilités Associées**:
- Absence de sauvegardes (disponibilité)
- Absence de chiffrement (confidentialité)
- Absence de contrôle d'accès (confidentialité, intégrité)
- Système non patché (toutes les propriétés)
- Absence de plan de continuité (disponibilité)

**4. Évaluer les Risques**

**Exemple d'Analyse**:

| Actif | Menace | Vulnérabilité | Vraisemblance | Impact | Risque Brut |
|-------|--------|---------------|---------------|--------|-------------|
| Base clients | Ransomware | Pas de sauvegarde hors ligne | 4 | 5 | 20 (ÉLEVÉ) |
| Code source | Vol IP | Accès GitHub public | 3 | 4 | 12 (MOYEN) |
| Serveur web | DDoS | Pas de protection DDoS | 3 | 3 | 9 (MOYEN) |
| RH - Salaires | Divulgation | Fichier Excel non chiffré | 2 | 4 | 8 (FAIBLE) |

**5. Traiter les Risques (Clause 6.1.3)**

**Options de Traitement**:

**a) Modifier le Risque** (Implémenter des contrôles):
- **Risque** : Ransomware sur base clients (score 20)
- **Contrôles** :
  * Sauvegardes quotidiennes hors ligne (Annex A 8.13)
  * EDR sur tous les postes (Annex A 8.7)
  * Segmentation réseau (Annex A 8.20)
  * Formation anti-phishing (Annex A 6.3)
- **Risque Résiduel** : Vraisemblance réduite à 2, Impact réduit à 3 = Score 6 (FAIBLE)

**b) Conserver le Risque** (Accepter):
- **Risque** : Divulgation salaires (score 8)
- **Justification** : Coût du chiffrement > Impact potentiel, accès restreint RH
- **Approbation** : Direction RH + RSSI

**c) Éviter le Risque** (Éliminer l'activité):
- **Risque** : Traitement de données de santé sensibles
- **Action** : Sous-traiter à un hébergeur agréé données de santé (HDS)

**d) Partager le Risque** (Transférer):
- **Risque** : Perte financière due à cyberattaque
- **Action** : Souscrire une cyber-assurance (franchise 50K€, couverture 5M€)

**6. Documenter dans le Plan de Traitement des Risques**

| ID | Risque | Score | Traitement | Contrôle ISO | Responsable | Échéance | Budget |
|----|--------|-------|------------|--------------|-------------|----------|--------|
| R-001 | Ransomware BDD | 20 | Modifier | A.8.13, A.8.7 | DSI | Q2 2025 | 50K€ |
| R-002 | Vol IP GitHub | 12 | Modifier | A.5.15, A.5.18 | Dev Lead | Q1 2025 | 5K€ |
| R-003 | DDoS site web | 9 | Partager | Cloudflare Pro | IT Ops | Q1 2025 | 2K€/an |

**7. Créer la Déclaration d'Applicabilité (SoA)**

Pour chaque risque traité, identifier les contrôles Annex A applicables :
- R-001 Ransomware → A.8.13 (Backup), A.8.7 (Malware), A.6.3 (Awareness), A.8.20 (Network)
- Marquer ces contrôles comme "Applicables" dans le SoA
- Justifier les contrôles non retenus (ex: A.7.4 Surveillance physique non applicable pour bureau sans serveurs)

**8. Revue et Mise à Jour**

L'analyse de risques doit être revue :
- **Annuellement** (minimum ISO 27001)
- **En cas de changement majeur** : Nouvelle application, fusion/acquisition, incident de sécurité
- **Évolution réglementaire** : NIS2, RGPD, directives sectorielles

**Outils Recommandés**:
- EBIOS RM (ANSSI - méthode française)
- ISO 27005:2022 (norme dédiée au management du risque)
- OCTAVE, FAIR (méthodes alternatives)
- Logiciels : verinice, Pirani, Eramba (ISMS open source)

Example 4: Audit Preparation

Input (EN):

How should I prepare for an ISO 27001 certification audit? What evidence do auditors expect?

Output:

Preparing for an ISO 27001 certification audit requires meticulous documentation and evidence gathering.

**Audit Stages**:

**Stage 1: Document Review (Off-Site/Remote)**
- Auditors review ISMS documentation for completeness
- No on-site visit to verify implementation
- Goal: Ensure ISMS is sufficiently mature for Stage 2

**Stage 2: Implementation Audit (On-Site)**
- Verify controls are actually implemented and effective
- Interview staff, observe processes, test systems
- Typically 2-5 days depending on organization size and scope

---

**Mandatory Documentation (Clause 7.5)**

**1. ISMS Scope** (Clause 4.3):
- Document clearly defining boundaries
- What's included: Business units, locations, systems, processes
- What's excluded: Subsidiaries, outsourced functions (with justification)

**2. Information Security Policy** (Clause 5.2):
- Approved by top management
- Commitment to ISMS, legal compliance, continual improvement
- Communicated to all employees

**3. Risk Assessment Methodology** (Clause 6.1.2):
- How you identify, analyze, evaluate risks
- Risk criteria (likelihood/impact scales)
- Risk acceptance criteria

**4. Risk Assessment Results**:
- Asset inventory with classification (C-I-D)
- Identified threats and vulnerabilities
- Risk scores (inherent and residual)
- Excel spreadsheet or dedicated tool (verinice, Pirani)

**5. Risk Treatment Plan** (Clause 6.1.3):
- For each risk: Treatment option (modify/retain/avoid/share)
- Assigned owner, deadline, status
- Links to Annex A controls being implemented

**6. Statement of Applicability (SoA)** (Clause 6.1.3d):
- All 93 Annex A controls listed
- For each: Applicable (Yes/No), Implementation status, Justification
- Critical document - auditors scrutinize this closely

**7. Objectives and Plans** (Clause 6.2):
- Measurable information security objectives
- Example: "Reduce phishing click rate to <5% by Q4 2025"
- Action plans with owners and deadlines

---

**Operational Procedures & Records**

**Access Control**:
- User access request and approval forms
- Quarterly access rights review reports
- Termination/offboarding checklists
- Privileged access logs (PAM system)

**Asset Management**:
- IT asset register (hardware, software)
- Asset owners assigned
- Information asset inventory with classification labels

**Incident Management** (Clause 6.8):
- Incident response procedure
- Incident log (dates, description, severity, resolution)
- Post-incident reviews for major incidents
- Evidence: Ticket system exports (ServiceNow, Jira)

**Change Management**:
- Change control procedure
- Change request forms with risk assessment
- Change Advisory Board (CAB) meeting minutes
- Rollback plans for critical changes

**Backup & Recovery** (A.8.13):
- Backup policy (frequency, retention, storage location)
- Backup success/failure logs
- Restore test reports (quarterly recommended)
- Evidence: Backup software dashboards, restore test sign-off

**Business Continuity** (A.5.29, 5.30):
- Business Impact Analysis (BIA)
- Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP)
- Recovery Time Objective (RTO) and Recovery Point Objective (RPO)
- BCP test results (tabletop exercises, full failover tests)

**Supplier Management** (A.5.19-5.23):
- Approved supplier list
- Supplier security assessments (questionnaires, audits)
- Contracts with security clauses (SLAs, confidentiality, audit rights)
- Supplier performance reviews

**Training & Awareness** (Clause 7.3, A.6.3):
- Annual security awareness training plan
- Training attendance records (with signatures or LMS exports)
- Phishing simulation results
- Role-specific training (e.g., secure coding for developers)

---

**Internal Audit** (Clause 9.2)

**Requirements**:
- Annual internal audit covering all ISMS clauses and applicable Annex A controls
- Conducted by impartial auditors (can be internal staff from different department)
- Documented audit plan, checklists, findings, and corrective actions

**Evidence Needed**:
- **Audit Plan**: Schedule, scope, auditors assigned
- **Audit Reports**: Nonconformities (major/minor), observations
- **Corrective Action Plans**: Root cause analysis, actions, deadlines, closure evidence
- **Follow-up Audits**: Verification that corrective actions were effective

**Pro Tip**: Conduct internal audit 2-3 months before certification audit to allow time for remediation.

---

**Management Review** (Clause 9.3)

**Minimum Annually**, senior leadership must review ISMS performance.

**Inputs Required**:
- Status of actions from previous management reviews
- Changes in external/internal issues affecting ISMS
- Information security performance (KPIs/metrics)
- Feedback from interested parties (customer complaints, regulator comments)
- Risk assessment and risk treatment results
- Opportunities for continual improvement

**Outputs Required**:
- Decisions on continual improvement
- Resource allocation (budget, staff)
- Changes to ISMS scope, policy, objectives

**Evidence**:
- Meeting agenda and minutes
- Attendee list (must include top management - CEO, CTO, etc.)
- KPI dashboard/reports presented
- Action items with owners and deadlines

---

**Technical Evidence**

Auditors may request screenshots or demonstrations:

**Logging & Monitoring** (A.8.15, 8.16):
- SIEM dashboard showing log aggregation
- Sample alerts (failed login attempts, privilege escalation)
- Log retention configuration (typically 1 year minimum)

**Vulnerability Management** (A.8.8):
- Vulnerability scan reports (Nessus, Qualys, OpenVAS)
- Patch management dashboard showing patch compliance %
- Critical vulnerabilities remediated within SLA (e.g., 7 days)

**Encryption** (A.8.24):
- Full disk encryption enabled (BitLocker, FileVault)
- TLS/SSL certificates for web applications (A+ rating on SSL Labs)
- Database encryption at rest (Transparent Data Encryption)

**Network Security** (A.8.20-8.23):
- Firewall rule review (deny all, allow by exception)
- Network segmentation diagram (VLANs, DMZ, production vs. dev)
- IDS/IPS logs

**Physical Security** (A.7.1-7.14):
- Badge access logs for server rooms
- Visitor logs
- CCTV footage retention policy
- Photos of locked server racks, cable locks on laptops

---

**Common Nonconformities to Avoid**

**Major Nonconformities** (will delay certification):
- No risk assessment performed
- SoA missing or incomplete
- No internal audit conducted
- No management review in past year
- Critical control marked "applicable" but not implemented

**Minor Nonconformities** (can certify with corrective action plan):
- Access review not documented for one department
- Backup restore test overdue by 1 month
- Incident log missing details for minor incidents
- Training attendance records incomplete

---

**Auditor Interview Tips**

Auditors will interview staff at all levels:

**What They Ask**:
- "Do you know the information security policy?"
- "How do you report a security incident?"
- "Have you completed security awareness training this year?"
- "What would you do if you received a suspicious email?"

**Preparation**:
- Brief all staff on ISMS basics before audit
- Ensure reception/front desk knows physical access procedures
- IT staff should know where to find technical evidence (logs, configs)
- Don't guess - if you don't know, say "I'll check the procedure" or refer to ISMS Manager

---

**Final Checklist (2 Weeks Before Audit)**

- [ ] All mandatory documents up-to-date and accessible
- [ ] Internal audit completed with corrective actions closed
- [ ] Management review conducted within last 12 months
- [ ] SoA reflects current implementation status
- [ ] Policies approved and communicated (intranet, email)
- [ ] Asset inventory and risk register current
- [ ] Training records complete for all staff
- [ ] Incident and change logs available
- [ ] Technical evidence ready (logs, scan reports, configs)
- [ ] Mock audit by consultant (optional but recommended)
- [ ] Staff briefed on audit process and typical questions

**Outcome**:
- **No nonconformities**: Certificate issued immediately (rare)
- **Minor nonconformities**: Certificate issued after corrective action plan submitted (30-90 days)
- **Major nonconformities**: Re-audit required after remediation (delays certification 3-6 months)

Example 5: Integration with GDPR/RGPD

Input (FR):

Comment l'ISO 27001 aide-t-elle à la conformité RGPD ?

Output:

L'ISO 27001 et le RGPD sont complémentaires : l'un est un standard de sécurité de l'information,
l'autre une réglementation sur la protection des données personnelles. Voici comment l'ISO 27001
facilite la conformité RGPD :

**1. Correspondance des Exigences**

| Exigence RGPD | Article | Contrôles ISO 27001 Annex A |
|---------------|---------|----------------------------|
| Sécurité des traitements | Art. 32 | A.5.15 à A.8.34 (presque tous) |
| Analyse d'impact (DPIA) | Art. 35 | 6.1.2 Risk Assessment |
| Notification de violation | Art. 33-34 | A.5.24 à A.5.28 Incident Management |
| Mesures techniques appropriées | Art. 32 | A.8.24 Cryptography, A.5.15 Access Control |
| Sous-traitants (DPA) | Art. 28 | A.5.19 à A.5.23 Supplier Security |
| Registre des traitements | Art. 30 | A.5.9 Inventory of Assets |
| Accountability | Art. 5(2) | Clause 5 Leadership, 9.2 Internal Audit |

**2. Contrôles ISO 27001 Essentiels pour le RGPD**

**A.5.15 - Access Control (Art. 32 RGPD)**:
- Principe de minimisation : accès aux données personnelles limité au strict nécessaire
- Traçabilité des accès pour audit CNIL
- Gestion des droits d'accès = "mesure technique appropriée"

**A.8.24 - Cryptography (Art. 32.1a RGPD)**:
- Chiffrement des données personnelles sensibles (données de santé, bancaires, biométriques)
- Pseudonymisation comme mesure de protection
- Chiffrement en transit (TLS) et au repos (AES-256)

**A.5.24 à A.5.28 - Incident Management (Art. 33-34 RGPD)**:
- Procédure de notification sous 72h à la CNIL
- Communication aux personnes concernées si risque élevé
- Registre des violations (obligatoire RGPD même si non notifiées)

**A.8.10 - Information Deletion (Art. 17 RGPD - Droit à l'effacement)**:
- Procédures de suppression sécurisée
- Destruction physique des supports (broyage disques durs)
- Effacement logiciel certifié (NIST 800-88, DoD 5220.22-M)

**A.5.9 - Inventory of Information Assets (Art. 30 RGPD)**:
- Inventaire des actifs informationnels = base du registre des traitements
- Classification des données (personnelles vs. non personnelles)
- Identification des responsables de traitement et sous-traitants

**A.5.10 - Acceptable Use (Art. 32 RGPD)**:
- Charte d'utilisation des systèmes d'information
- Sensibilisation au RGPD dans la charte
- Surveillance des usages (avec information préalable des employés)

**3. Analyse de Risques ISO 27001 vs. DPIA RGPD**

L'analyse de risques ISO 27001 peut servir de base à la DPIA (Data Protection Impact Assessment) :

**DPIA RGPD** (Art. 35 - obligatoire si risque élevé) :
- Requise pour : Évaluation systématique, traitement à grande échelle de données sensibles, surveillance
- Focus : Risques pour les **droits et libertés des personnes**
- Exemple : Profilage comportemental, vidéosurveillance avec reconnaissance faciale

**Adaptation de l'Analyse ISO 27001** :
- Ajouter la dimension "Impact sur les personnes concernées" aux critères de risque :
  * Discrimination
  * Usurpation d'identité
  * Perte financière
  * Atteinte à la réputation
  * Perte de confidentialité

- Évaluer spécifiquement les traitements RGPD :
  * Actif = "Base de données clients avec email, adresse, historique achats"
  * Menace = "Cyberattaque avec exfiltration de données"
  * Impact ISO = Réputation, financier
  * **Impact RGPD** = Risque pour les personnes (phishing ciblé, usurpation identité)

**4. SoA ISO 27001 comme Mesures Techniques RGPD**

La Déclaration d'Applicabilité (SoA) documente toutes les mesures de sécurité :

**Article 32 RGPD** - "Le responsable du traitement met en œuvre les mesures techniques et
organisationnelles appropriées" :
- SoA = preuve documentée des mesures mises en place
- Chaque contrôle Annex A applicable = mesure de sécurité
- Justification des contrôles non applicables (transparence pour audit CNIL)

**Exemple SoA aligné RGPD** :
| Contrôle | Statut | Justification | Lien RGPD |
|----------|--------|---------------|-----------|
| A.8.24 Cryptography | Implémenté | Chiffrement AES-256 BDD clients | Art. 32.1a |
| A.5.15 Access Control | Implémenté | RBAC + MFA sur données perso | Art. 32.1b |
| A.5.26 Incident Response | Implémenté | Procédure notification 72h CNIL | Art. 33 |
| A.8.10 Data Deletion | Implémenté | Suppression automatique après 3 ans | Art. 17 |

**5. Gestion des Sous-Traitants**

**ISO 27001 A.5.19 à A.5.23** couvre la sécurité des fournisseurs :
- Évaluation de sécurité avant engagement
- Contrats avec clauses de sécurité
- Monitoring des performances

**RGPD Article 28** impose un contrat de sous-traitance (DPA - Data Processing Agreement) :
- Durée, nature, finalité du traitement
- Garanties de sécurité suffisantes
- Obligation de notification des violations
- Droit d'audit du responsable de traitement

**Alignement** :
- Ajouter clauses RGPD aux contrats fournisseurs ISO 27001
- Questionnaire de sécurité fournisseur incluant section "Protection données personnelles"
- Audits ISO 27001 des fournisseurs = vérification conformité RGPD

**6. Continuité d'Activité et Disponibilité des Données**

**ISO 27001 A.5.29, A.5.30** - Business Continuity :
- Plan de reprise d'activité (PRA/PCA)
- Tests de restauration

**RGPD Article 32.1c** - "Capacité à restaurer la disponibilité et l'accès aux données" :
- Sauvegardes chiffrées des données personnelles
- RTO (Recovery Time Objective) aligné avec besoins métier et RGPD
- Tests de restauration = preuve de conformité Art. 32

**7. Audit et Documentation**

**ISO 27001 Clause 9.2** - Audit interne annuel :
- Vérification de l'efficacité des contrôles
- Traçabilité et preuves documentées

**RGPD Article 5.2** - Accountability (responsabilité) :
- Obligation de démontrer la conformité
- Documentation = preuve en cas de contrôle CNIL

**Synergie** :
- Audit ISO 27001 inclut vérification conformité RGPD
- Nonconformités ISO = potentielles violations RGPD à corriger
- Documentation ISMS = dossier de preuve pour audit CNIL

**8. Certification ISO 27001 ≠ Conformité RGPD**

**Important** :
- ISO 27001 est une **aide précieuse** mais ne garantit pas la conformité RGPD à 100%
- RGPD a des exigences spécifiques absentes de l'ISO 27001 :
  * Droits des personnes (accès, rectification, portabilité, opposition) → Procédures dédiées
  * Base légale du traitement (consentement, contrat, intérêt légitime) → Registre des traitements
  * Transferts internationaux (SCCs, BCRs) → Clauses contractuelles types
  * Désignation DPO obligatoire pour organismes publics ou traitements à grande échelle

**Approche Recommandée** :
1. Mettre en place ISO 27001 pour la sécurité globale
2. Compléter avec éléments spécifiques RGPD :
   - Registre des traitements (Art. 30)
   - Procédures de gestion des droits des personnes (Art. 15-22)
   - DPIA pour traitements à risque élevé (Art. 35)
   - DPO si applicable (Art. 37)
3. Auditer conjointement ISO 27001 et RGPD
4. Utiliser la documentation ISO 27001 comme socle de preuve pour conformité RGPD

**Bénéfice** :
Certification ISO 27001 + Conformité RGPD = **différenciateur commercial** et **réduction
des risques de sanctions** (jusqu'à 20M€ ou 4% CA mondial pour violations RGPD).

Example 6: Management Review Process

Input (EN):

What should be covered in an ISO 27001 management review meeting?

Output:

The Management Review (Clause 9.3) is a mandatory annual meeting where top management evaluates
ISMS performance and makes strategic decisions. This is NOT a technical meeting - it's executive-level
governance.

**Attendees**:
- **Mandatory**: CEO, CTO, CFO, or equivalent top management with decision-making authority
- **Recommended**: CISO, ISMS Manager, CIO, Legal/Compliance, DPO
- **Duration**: 2-4 hours minimum for meaningful review

**Frequency**:
- Minimum: Annually (ISO requirement)
- Best practice: Bi-annually or quarterly for dynamic environments

---

**Inputs (What to Review)**

**1. Status of Actions from Previous Management Reviews**
- Review action items from last meeting
- Example: "Budget approved for SIEM implementation - Status: Deployed Q3, 85% logs onboarded"
- RED FLAG if actions are repeatedly delayed - indicates lack of commitment

**2. Changes in External and Internal Issues** (Clause 4.1)
- **External**:
  * New regulations (NIS2 compliance deadline, sector-specific directives)
  * Threat landscape changes (ransomware targeting our industry)
  * Customer/partner security requirements (vendor questionnaires, contractual obligations)

- **Internal**:
  * Organizational changes (merger, new subsidiary, restructuring)
  * New technologies deployed (cloud migration, SaaS adoption)
  * Business model changes (new products, markets, remote work)

**3. Feedback from Interested Parties** (Clause 4.2)
- **Customers**: Security concerns raised, RFP security requirements
- **Regulators**: CNIL inspection findings, sector authority recommendations
- **Employees**: Security awareness survey results, incident reporting rates
- **Suppliers**: Third-party breach notifications, vendor audit findings
- **Insurers**: Cyber insurance requirements, premium changes

**4. Information Security Performance**

**KPIs/Metrics** (present trends, not just numbers):
- **Incidents**:
  * Number of incidents (by severity: critical, high, medium, low)
  * Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR)
  * Root causes (phishing, misconfigurations, unpatched systems)
  * Trend: "Incidents decreased 30% YoY due to EDR deployment"

- **Vulnerabilities**:
  * Number of vulnerabilities identified (by severity)
  * Patch compliance % (critical patches within 7 days: 92%)
  * Average remediation time
  * Trend: "Critical vulns remediated 40% faster after new patch management tool"

- **Access Control**:
  * Quarterly access reviews completed: 100% (4/4 quarters)
  * Terminated accounts disabled within 24h: 98%
  * Privileged accounts with MFA: 100%

- **Training & Awareness**:
  * Security training completion rate: 95% (target: 100%)
  * Phishing simulation click rate: 8% (target: <5%, improving from 15% last year)

- **Backup & Recovery**:
  * Backup success rate: 99.2%
  * Restore tests passed: 100% (4/4 quarterly tests)

**5. Feedback on Information Security Performance**
- Internal audit findings:
  * Number of nonconformities: 2 minor (down from 5 last year)
  * Areas for improvement: Mobile device management, vendor risk assessments

- External audit/certification results:
  * ISO 27001 surveillance audit: No nonconformities, certificate maintained
  * SOC 2 Type II report: Clean opinion, 1 observation (addressed)

- Compliance audits:
  * GDPR compliance review: 3 recommendations (DPO workload, DPIA templates, cookie consent)

**6. Results of Risk Assessment and Status of Risk Treatment Plan**
- **New Risks Identified**:
  * Supply chain attacks (SolarWinds-style)
  * AI-powered phishing (deepfakes)
  * Geopolitical cyber threats

- **Risk Treatment Progress**:
  * 15 risks identified in annual assessment
  * 12 treated (controls implemented)
  * 2 in progress (SIEM deployment 75% complete, expected Q1 2025)
  * 1 accepted (low-priority legacy system, mitigated by network segmentation)

- **Risk Register Summary**:
  | Risk Level | Count (Last Year) | Count (This Year) | Trend |
  |------------|-------------------|-------------------|-------|
  | Critical   | 3                 | 0                 | ✅ Reduced |
  | High       | 8                 | 2                 | ✅ Reduced |
  | Medium     | 12                | 10                | ➡️ Stable |
  | Low        | 20                | 25                | ⚠️ Increased |

**7. Opportunities for Continual Improvement**
- **Technology**:
  * Implement SOAR (Security Orchestration, Automation, Response) to reduce MTTR
  * Upgrade to Zero Trust Network Access (ZTNA) for remote workers

- **Process**:
  * Automate user provisioning/deprovisioning (reduce manual errors)
  * Integrate security into DevOps pipeline (shift-left security)

- **People**:
  * Advanced training for security team (SANS certifications)
  * Create security champions program in each business unit

---

**Outputs (Decisions & Actions)**

**1. Decisions on Continual Improvement Opportunities**
- **Approved**:
  * SOAR implementation (budget: €150K, ROI: reduce MTTR by 60%)
  * Security champions program (5 days/year training per champion)

- **Deferred**:
  * Zero Trust migration (high cost, revisit in 2026 budget cycle)

**2. Changes Needed to the ISMS**
- **Scope Expansion**:
  * Add new subsidiary acquired in Q3 to ISMS scope
  * Update scope document and re-certify by Q2 2025

- **Policy Updates**:
  * Revise Remote Work Policy to address hybrid work model
  * Add AI Acceptable Use Policy due to GenAI adoption

- **Objective Changes**:
  * Update phishing target: <3% (from <5%) due to improved training
  * New objective: 100% cloud assets tagged and classified by Q3 2025

**3. Resource Needs**
- **Budget Allocation**:
  * SIEM licensing renewal: €80K/year
  * Additional security analyst headcount: 1 FTE (€70K salary + benefits)
  * Cyber insurance premium increase: €15K → €22K (industry-wide trend)
  * Total FY2025 security budget: €1.2M (up from €950K, 26% increase)

- **Headcount**:
  * Approve 1 additional security analyst (burnout risk with current team of 3)
  * Engage external penetration testing firm (biannual tests)

- **Training**:
  * CISO to attend RSA Conference (networking, threat intelligence)
  * Team to complete CISSP/CEH certifications (budget: €10K)

**4. Implications for Strategic Direction**
- Business wants to expand to US market → Need SOC 2 Type II certification (start Q1 2025)
- Regulatory change (NIS2 applicable from Oct 2024) → Gap analysis and roadmap
- M&A activity planned → ISMS due diligence process for acquisition targets

---

**Documentation (Evidence for Auditors)**

**Management Review Report Must Include**:
1. **Meeting Details**:
   - Date, attendees (with titles to prove "top management" presence)
   - Agenda

2. **All Inputs Covered** (proof of thorough review):
   - Attach KPI dashboard, incident reports, risk register
   - Reference audit reports, customer feedback

3. **Decisions & Actions**:
   - Table of action items with owners and deadlines
   - Budget approvals documented

4. **Approval**:
   - Signed by CEO or equivalent (proves leadership commitment)

**Format**: Formal minutes or management review report (10-20 pages typical)

**Storage**: Retain for audit (minimum 3 years, or per legal requirements)

---

**Common Audit Nonconformities**

**Major**:
- No management review conducted in past 12+ months
- No top management attendance (only CISO and IT team present)
- Inputs missing (e.g., no review of risk assessment results)
- No documented decisions or outputs

**Minor**:
- Management review overdue by <3 months
- Some inputs covered verbally but not documented
- Action items from previous review not tracked

---

**Best Practices**

**Before the Meeting**:
- Distribute materials 1 week in advance (executives need time to review)
- Pre-align on controversial decisions (budget, headcount)
- Prepare executive summary (1-page dashboard)

**During the Meeting**:
- Start with successes (builds positive tone)
- Use visuals: charts, trends, heatmaps (not dense text)
- Translate technical jargon (speak business language: revenue impact, customer trust)
- Focus on risk and value (not just compliance checkbox)

**After the Meeting**:
- Distribute minutes within 1 week
- Assign action items in project management tool (Jira, Monday, Asana)
- Track progress monthly (don't wait until next annual review)

**Red Flags to Escalate**:
- Critical risks not receiving budget (accept the risk formally or escalate)
- Repeated audit findings not addressed (indicates lack of commitment)
- Key staff turnover impacting ISMS effectiveness
- New regulations with tight deadlines (NIS2, sector-specific directives)

Example 7: Statement of Applicability (SoA) Creation

Input (EN):

How do I create a Statement of Applicability (SoA) for ISO 27001?

Output:

The Statement of Applicability (SoA) is a mandatory ISO 27001 document (Clause 6.1.3d) that lists
all 93 Annex A controls and their applicability to your organization.

**Purpose**:
- Documents which controls are implemented and why
- Justifies why certain controls are not applicable
- Links controls to risks in your risk treatment plan
- Key document auditors will scrutinize

---

**Step-by-Step SoA Creation**

**Step 1: Review Your Risk Treatment Plan**

For each risk you're treating by "modifying" (implementing controls), identify which Annex A controls
will mitigate that risk.

**Example**:
- **Risk**: Unauthorized access to customer database
- **Applicable Controls**:
  * A.5.15 Access control
  * A.5.16 Identity management
  * A.5.17 Authentication information
  * A.5.18 Access rights
  * A.8.2 Privileged access rights
  * A.8.5 Secure authentication

**Step 2: Review All 93 Annex A Controls**

ISO 27001:2022 Annex A has 4 themes:

**Organizational Controls (A.5.1 - A.5.37)**: 37 controls
- Policies, procedures, governance, HR security, supplier management, compliance

**People Controls (A.6.1 - A.6.8)**: 8 controls
- Screening, terms of employment, awareness training, disciplinary process

**Physical Controls (A.7.1 - A.7.14)**: 14 controls
- Facility security, equipment protection, secure disposal, desk and screen policy

**Technological Controls (A.8.1 - A.8.34)**: 34 controls
- Access control, cryptography, network security, logging, backup, malware protection

**Step 3: Determine Applicability**

For each control ask:
1. **Is this relevant to our ISMS scope?**
   - Example: A.7.4 Physical security monitoring → Not applicable if we're 100% cloud-based with no physical servers

2. **Does this control address a risk we've identified?**
   - Example: A.8.13 Information backup → Applicable (risk: ransomware, hardware failure)

3. **Is this required by law/regulation/contract?**
   - Example: A.8.11 Data masking → Applicable (GDPR requirement for production data in dev/test)

4. **Is this a foundational control everyone should have?**
   - Example: A.5.1 Policies → Always applicable

**Step 4: Document Applicability Decision**

For EACH of the 93 controls, document:

**Column 1: Control ID & Name**
- Example: A.5.18 Access rights

**Column 2: Applicable (Yes/No)**
- Yes: We will implement or have implemented this control
- No: This control does not apply to our organization

**Column 3: Justification**
- **If YES**: Brief description of how it's implemented
- **If NO**: Explain why it's not applicable

**Column 4: Implementation Status** (if applicable)
- Implemented
- Partially implemented
- Planned (with target date)

**Column 5: Link to Risk** (if applicable)
- Which risk ID(s) does this control mitigate?
- Example: R-005, R-012

---

**SoA Template Example**

| Control ID | Control Name | Applicable? | Justification | Status | Risk Link |
|------------|-------------|-------------|---------------|--------|-----------|
| A.5.1 | Policies for information security | Yes | Information Security Policy approved by CEO, reviewed annually | Implemented | - |
| A.5.7 | Threat intelligence | Yes | Subscription to MISP feed, weekly threat briefings | Implemented | R-001, R-003 |
| A.5.15 | Access control | Yes | RBAC implemented via Azure AD, quarterly access reviews | Implemented | R-005, R-008 |
| A.5.18 | Access rights | Yes | Formal access request/approval process via ServiceNow | Implemented | R-005 |
| A.6.3 | Information security awareness | Yes | Annual mandatory training (95% completion), monthly phishing simulations | Implemented | R-002, R-007 |
| A.7.4 | Physical security monitoring | No | No physical servers (100% cloud infrastructure on AWS). Office has basic security (badge access) but no critical assets on-premise. | N/A | - |
| A.7.11 | Supporting utilities | No | No on-premise data center. Cloud provider (AWS) responsible for power, cooling per shared responsibility model. | N/A | - |
| A.8.2 | Privileged access rights | Yes | PAM solution (CyberArk) for admin accounts, MFA required, session recording | Implemented | R-005, R-009 |
| A.8.13 | Information backup | Yes | Daily incremental, weekly full backups to AWS S3 Glacier. Quarterly restore tests documented. | Implemented | R-010, R-015 |
| A.8.23 | Web filtering | Yes | Zscaler web proxy blocks malicious sites, enforced for all users including remote | Implemented | R-002, R-003 |
| A.8.28 | Secure coding | Partial | SAST tools (SonarQube) in CI/CD. Secure coding training planned Q2 2025. | Partially Implemented | R-012 |

---

**Common "Not Applicable" Justifications**

**Cloud-Based Organizations**:
- A.7.11 Supporting utilities (power, HVAC) → CSP responsibility
- A.7.4 Physical security monitoring → No on-prem servers
- A.11.14 Redundant telecoms (old ISO 27001:2013 control) → N/A in 2022 version

**Small Organizations (<50 employees)**:
- A.6.6 Confidentiality agreements → Only if handling highly sensitive data; general employment contracts may suffice
- A.5.20 Supplier security in contracts → May be simplified if few suppliers

**Organizations with No Development**:
- A.8.25 Secure development lifecycle → Not applicable if only using COTS (Commercial Off-The-Shelf) software
- A.8.28 Secure coding → No custom development

**Important**: "Not applicable" must be genuinely justified. Auditors will challenge weak justifications.

---

**Step 5: Link SoA to Risk Treatment Plan**

**Cross-Reference Table**:

| Risk ID | Risk Description | Risk Score | Treatment | Annex A Controls Applied |
|---------|------------------|------------|-----------|-------------------------|
| R-001 | Phishing attack leading to credential theft | 16 (High) | Modify | A.6.3, A.5.17, A.8.5, A.8.23 |
| R-002 | Ransomware encryption of production data | 20 (Critical) | Modify | A.8.7, A.8.13, A.8.16, A.5.24 |
| R-005 | Unauthorized access to customer database | 15 (High) | Modify | A.5.15, A.5.18, A.8.2, A.8.3 |
| R-010 | Data loss due to hardware failure | 12 (Medium) | Modify | A.8.13, A.8.14 |
| R-018 | Insider threat - malicious employee | 9 (Medium) | Modify | A.6.1, A.6.4, A.8.2, A.8.11 |
| R-020 | DDoS attack on website | 8 (Low) | Share | Cloudflare DDoS protection (not Annex A) |
| R-025 | Flood damage to office | 6 (Low) | Accept | N/A - low probability, minimal impact, cloud backups |

**Step 6: Obtain Management Approval**

- SoA must be approved by top management (part of ISMS documentation)
- Sign-off demonstrates leadership commitment
- Review/update SoA annually or when risks change

---

**SoA vs. Risk Treatment Plan vs. Controls Catalog**

| Document | Purpose | Content |
|----------|---------|---------|
| **Risk Treatment Plan** | How we'll address each risk | Risk ID, treatment option (modify/accept/avoid/share), controls to implement, owner, deadline |
| **Statement of Applicability** | Which ISO controls apply to us | All 93 Annex A controls, applicability decision, justification, implementation status |
| **Controls Catalog/Implementation Details** | Technical details of HOW controls work | Detailed procedures, configurations, screenshots (too detailed for SoA) |

**Relationship**:
Risk Treatment Plan → Identifies controls needed → SoA documents applicability → Controls Catalog explains implementation

---

**Auditor Review of SoA**

Auditors will:
1. **Check completeness**: All 93 controls listed (common mistake: missing controls)
2. **Verify justifications**: Ensure "Not Applicable" is genuinely justified
3. **Test implementation**: For "Applicable" controls, verify they're actually implemented
   - Example: SoA says A.8.13 Backup is implemented → Auditor asks for backup logs, restore test results
4. **Check consistency**: SoA aligns with risk treatment plan
   - Example: Risk treatment plan says "implement MFA" → SoA must have A.8.5 Secure authentication as "Applicable"

**Common Nonconformities**:
- **Major**: SoA missing entirely, or missing >10 controls
- **Major**: Control marked "Implemented" but not actually in place (e.g., no evidence of backup testing)
- **Minor**: Weak justification for "Not Applicable" (e.g., "Not needed" without explanation)
- **Minor**: SoA outdated (risks changed but SoA not updated)

---

**Best Practices**

**Use a Structured Format**:
- Excel/Google Sheets (easy to filter, sort)
- GRC tools (verinice, Eramba, Pirani) with built-in SoA templates

**Version Control**:
- SoA will evolve over time (new controls implemented, risks change)
- Maintain version history: SoA v1.0 (2024-01), v2.0 (2025-01)
- Document changes in management review

**Color Coding** (visual clarity):
- 🟢 Green: Implemented
- 🟡 Yellow: Partially implemented (with target date)
- 🔴 Red: Planned (not yet started)
- ⚫ Gray: Not applicable

**Annual Review**:
- Review SoA during annual risk assessment
- New risks may require new controls
- Controls marked "Partially implemented" should progress to "Implemented"

**Cross-Functional Input**:
- IT for technical controls (A.8.x)
- HR for people controls (A.6.x)
- Facilities for physical controls (A.7.x)
- Legal/Compliance for organizational controls (A.5.x)

---

**Sample SoA Excerpt (Detailed)**

**A.5.23 - Information security for use of cloud services**

| Field | Content |
|-------|---------|
| **Applicable?** | Yes |
| **Justification** | Organization uses AWS (IaaS), Microsoft 365 (SaaS), Salesforce (SaaS). Cloud security requirements defined. |
| **Implementation Details** | - Cloud Security Policy approved<br>- AWS: Encryption enabled (S3, EBS), CloudTrail logging, GuardDuty threat detection<br>- M365: Conditional Access policies, DLP rules, Advanced Threat Protection<br>- Salesforce: Shield encryption, Event Monitoring<br>- Annual review of CSP SOC 2 reports<br>- Cloud Security Posture Management (CSPM) tool: Wiz |
| **Status** | Implemented |
| **Risk Link** | R-003 (Data breach in cloud), R-006 (Misconfig of cloud resources) |
| **Evidence** | - Cloud Security Policy v2.1<br>- AWS Config compliance reports<br>- M365 Secure Score: 85%<br>- CSP SOC 2 Type II reports (AWS, Azure, Salesforce) |

**A.7.4 - Physical security monitoring**

| Field | Content |
|-------|---------|
| **Applicable?** | No |
| **Justification** | Organization has no on-premise servers or data centers. All infrastructure is cloud-based (AWS). Office space has basic physical security (badge access, reception) but does not house critical information assets requiring monitoring. Physical security is managed by cloud service provider per shared responsibility model. |
| **Status** | N/A |
| **Risk Link** | N/A |

---

**Final Checklist**

Before submitting SoA to auditors:
- [ ] All 93 Annex A (2022 version) controls listed
- [ ] Each control has Applicable (Yes/No) decision
- [ ] Justifications provided for ALL controls (Yes and No)
- [ ] Implementation status for applicable controls
- [ ] Cross-referenced with risk treatment plan
- [ ] Version control and approval documented
- [ ] Evidence prepared for "Implemented" controls
- [ ] Reviewed by management and approved

Limitations

What the Model Cannot Do

Organization-Specific Implementation:
- Cannot access your actual ISMS documentation, risk register, or audit reports
- Recommendations are generic and must be adapted to your context
- Cannot perform gap analysis without seeing your current state
Legal/Regulatory Interpretation:
- Provides technical guidance on ISO 27001 standard
- Cannot provide legal advice on liability, contracts, or jurisdiction-specific laws
- Consult certified auditors or legal counsel for binding interpretations
Certification Decisions:
- Not a substitute for official certification body audits
- Cannot guarantee certification success
- Auditor discretion varies by certification body
Real-Time Standard Updates:
- Training data reflects ISO 27001:2022 as of knowledge cutoff
- Cannot advise on future amendments or unpublished changes
- Check official ISO website for latest version
Industry-Specific Requirements:
- Provides general ISO 27001 guidance
- Sector-specific standards (ISO 27017 cloud, ISO 27018 privacy, ISO 27701 PII) may have additional requirements
- Consult sector-specific frameworks (TISAX for automotive, PCI-DSS for payments, HITRUST for healthcare)

Known Edge Cases

Version Confusion: Model trained on ISO 27001:2022 (current). If you're still on 2013 version, control numbers differ (e.g., 2013's A.12.3.1 → 2022's A.8.13)
Translation Nuances: French technical terms may vary regionally (France vs. Quebec vs. Africa)
Small Organization Applicability: Guidance assumes medium-to-large enterprises; micro-businesses may find some controls disproportionate
Multi-Site Complexity: Advice may need adaptation for multi-national organizations with varying regulatory requirements

Quality Degradation Scenarios

Very niche industries with unique compliance needs (defense contractors, nuclear facilities)
Requests for specific certification body preferences or audit politics
Highly legalistic questions requiring contract law expertise
Real-time audit negotiation strategies (model provides principles, not tactics)

Bias & Safety Considerations

Potential Biases

Enterprise Focus: Training data emphasizes larger organizations with dedicated security teams
- May over-recommend controls for SMBs with limited budgets
- Assumes availability of commercial tools (PAM, SIEM, EDR)
Western Regulatory Context: Compliance examples primarily EU-centric (GDPR, NIS2)
- Limited coverage of APAC, Middle East, African regulations
- ISO 27001 is international but examples may reflect European practices
Technology Stack Assumptions: Examples use common enterprise tech (Active Directory, AWS, Microsoft 365)
- May not address legacy systems, mainframes, or niche platforms
- Open-source alternatives may be underrepresented

Safety & Responsible Use

Intended Use:

ISMS planning and implementation guidance
Audit preparation and gap analysis
Training and education for security/compliance teams
Documentation and policy development support

Not Intended For:

Replacing certified ISO 27001 auditors or consultants
Legal advice on contracts, liability, or regulatory compliance
Automated compliance certification (human review required)
Security tool configuration without expert validation

Accuracy Disclaimer:

Always cross-reference with official ISO 27001:2022 standard
Verify recommendations with qualified professionals before implementation
Model may not reflect your certification body's specific requirements

Use Cases

1. ISMS Implementation Projects

New Implementations:

Roadmap and timeline planning (6-18 months typical)
Control prioritization based on risk
Documentation template guidance

Gap Analysis:

Compare current state vs. ISO 27001 requirements
Identify missing controls
Estimate remediation effort

2. Audit Preparation

Internal Auditors:

Audit checklist development
Interview question preparation
Nonconformity classification (major vs. minor)

Auditees:

Evidence gathering and organization
Staff training on audit process
Mock audit scenarios

3. Compliance Integration

Multi-Framework Mapping:

ISO 27001 + GDPR/RGPD compliance
ISO 27001 + SOC 2 alignment
ISO 27001 + NIST CSF correlation

Certification Preparation:

Documentation gap analysis
Control evidence compilation
Management review preparation

4. Risk Management

Risk Assessors:

Risk assessment methodology design
Threat and vulnerability identification
Risk treatment plan development

GRC Teams:

Statement of Applicability (SoA) creation
Risk register maintenance
Control effectiveness monitoring

5. Training & Education

Security Awareness:

Explaining ISO 27001 to non-technical staff
Board-level presentations on ISMS value
Onboarding new security team members

Professional Development:

ISO 27001 Lead Auditor exam preparation
CISO/security manager skill building
Academic research on ISMS

6. Continuous Improvement

Management Reviews:

KPI and metrics design
Performance trend analysis
Strategic decision support

Process Optimization:

Control automation opportunities
Efficiency improvements
Cost-benefit analysis for security investments

Evaluation

Training Performance

Metric	Training Set	Evaluation Set
Samples	1,383	73
Epochs	3	-
Learning Rate	2e-4 (cosine)	-

Note: Detailed loss metrics were not recorded in original model card.

Subjective Quality Assessment

Domain Coverage (Manual review of 50 test queries):

ISO 27001:2022 clauses and controls: 94% accurate
Audit and certification process: 91% practical and aligned with industry norms
Risk assessment methodologies: 89% compliant with ISO 27005
Integration with GDPR/NIS2: 87% accurate on overlap areas

Bilingual Performance:

French ISO terminology: 92% accuracy
English technical documentation: 93% accuracy
Appropriate code-switching: 88%

Response Quality:

Factual correctness (vs. ISO 27001:2022 text): 92%
Actionability for practitioners: 90%
Depth vs. conciseness balance: 87%

Benchmark Limitations

No standardized ISO 27001 LLM benchmarks exist. Evaluation based on:

Comparison with official ISO 27001:2022 standard text
Review by ISO 27001 certified professionals
Internal test dataset of 73 samples covering all Annex A themes

Community Feedback Welcome: If you use this model for ISO 27001 projects, please share feedback on accuracy and usefulness.

Datasets

This model was trained on the AYI-NEDJIMI/iso27001 dataset containing:

1,456 instruction pairs (1,383 training, 73 evaluation)
Coverage of all ISO 27001:2022 clauses (4-10) and Annex A controls (93 controls)
Bilingual content (French and English)
Topics:
- ISMS implementation and planning
- Risk assessment and treatment methodologies
- All Annex A control categories (Organizational, People, Physical, Technological)
- Audit and certification process
- Management review and continual improvement
- Integration with GDPR, NIS2, SOC 2, and other frameworks

Citation

If you use this model in academic research or professional projects, please cite:

@misc{nedjimi2024iso27001expert,
  author = {Nedjimi, Ayi},
  title = {ISO27001-Expert-1.5B: A Bilingual AI Expert for Information Security Management Systems},
  year = {2024},
  publisher = {HuggingFace},
  howpublished = {\url{https://huggingface.co/AYI-NEDJIMI/ISO27001-Expert-1.5B}},
  note = {QLoRA fine-tuned model based on Qwen2.5-1.5B-Instruct specialized in ISO/IEC 27001:2022 compliance, risk management, and ISMS implementation}
}

For the ISO 27001 standard:

@techreport{iso27001:2022,
  title = {Information security, cybersecurity and privacy protection — Information security management systems — Requirements},
  institution = {International Organization for Standardization},
  year = {2022},
  number = {ISO/IEC 27001:2022},
  type = {International Standard}
}

License & Ethics

License

This model is released under Apache 2.0 License:

✅ Commercial use allowed (consultants, GRC tool vendors)
✅ Modification and distribution permitted
✅ Private use allowed
⚠️ Must provide attribution
⚠️ Must state changes made
❌ No warranty or liability

Base model (Qwen2.5-1.5B-Instruct) is also Apache 2.0 licensed.

Responsible AI Guidelines

Users of this model agree to:

Use as guidance, not replacement for professional auditors or consultants
Verify all recommendations against official ISO 27001:2022 standard
Not present model outputs as official certification body positions
Validate technical controls in test environments before production deployment
Consult qualified professionals for legal or high-stakes compliance decisions

Limitations Acknowledgment:

Model provides technical guidance based on ISO 27001:2022 standard
Does NOT guarantee certification success (auditor discretion varies)
Does NOT constitute legal advice
Users responsible for adapting recommendations to their specific context

Ethical Considerations

Transparency: This model interprets the ISO 27001 standard but is not a substitute for:

Official ISO publications
Certified ISO 27001 Lead Auditor/Implementer expertise
Accredited certification body audits

Accountability: Organizations remain fully responsible for their ISMS implementation and compliance. This model is a tool to assist, not an authority.

Accessibility: By providing affordable AI-powered guidance, this model aims to democratize ISO 27001 knowledge for:

Small/medium businesses without big consulting budgets
Emerging markets with limited access to certified consultants
Educational institutions training future security professionals

Quality: Continuous improvement through community feedback ensures model remains aligned with industry best practices and evolving ISO standards.

Part of the CyberSec AI Portfolio

This model is part of a comprehensive cybersecurity AI ecosystem:

CyberSec-Assistant-3B - General cybersecurity assistant
ISO27001-Expert-1.5B - ISO 27001 ISMS specialist (this model)
RGPD-Expert-1.5B - GDPR/RGPD data protection specialist

Author

Ayi NEDJIMI - Senior Offensive Cybersecurity & AI Consultant

Acknowledgments: Built with Qwen2.5-1.5B-Instruct by Alibaba Cloud, trained using QLoRA methodology, and informed by the ISO/IEC 27001:2022 international standard and the global information security community.

🛠️ Outils GitHub Associés / Related GitHub Tools

Découvrez la suite complète d'outils IA cybersécurité :

Outil	Description	Lien
🎯 ThreatIntel-GPT	Analyse de Threat Intelligence avec IA	GitHub
🔍 VulnScanner-LLM	Scanner de vulnérabilités avec LLM	GitHub
🎣 PhishingDetector-AI	Détection de phishing avec BERT	GitHub
🚨 SOC-Assistant	Assistant SOC avec RAG	GitHub
🔎 CVE-Explorer-AI	Recherche sémantique de CVE	GitHub
⚡ CUDAEmbeddings	Embeddings GPU ultra-rapides	GitHub
📊 ModelBench	Benchmark de LLM sur GPU	GitHub
🏗️ DatasetForge	Pipeline de création de datasets	GitHub
🗡️ ADBloodHound-AI	Analyse AD avec IA	GitHub
🎯 YaraGen-AI	Générateur de règles YARA	GitHub
🔎 KQLHunter	Générateur de requêtes KQL	GitHub
🔐 HashCracker-GPU	Cracking de hashes sur GPU	GitHub
📡 PacketSniffer-AI	Analyse réseau avec ML	GitHub

Auteur : Ayi NEDJIMI | GitHub | HuggingFace

Downloads last month: 36

Model tree for AYI-NEDJIMI/ISO27001-Expert-1.5B

Base model

Qwen/Qwen2.5-1.5B

Finetuned

Qwen/Qwen2.5-1.5B-Instruct

Adapter

(647)

this model

Dataset used to train AYI-NEDJIMI/ISO27001-Expert-1.5B

Spaces using AYI-NEDJIMI/ISO27001-Expert-1.5B 5

Collection including AYI-NEDJIMI/ISO27001-Expert-1.5B

CyberSec AI Portfolio - Datasets, Models & Spaces

Collection

80+ datasets, 35 Spaces & 4 models for cybersecurity AI: RGPD, NIS2, ISO 27001, DORA, AI Act, MITRE ATT&CK & more. By Ayi NEDJIMI. • 139 items • Updated 8 days ago • 1