A CISO's Playbook: How to Map the ISO 27001:2022 Human Controls (Annex A.6)

The 2022 revision of ISO 27001 represents a structural evolution by consolidating all people-centric security measures into a single, dedicated domain: Annex A.6 People controls. This structural change mirrors the core principle of the new NIS2 Directive, transforming human risk from a "soft" HR topic into a top-tier, auditable security domain for which C-level management is now personally liable.

For CISOs and HR Directors in regulated sectors, this means the era of performative compliance is officially over. Simply "having" a training program (formerly control A.7.2.2) is no longer sufficient. With data breaches consistently linked to human error, auditors now demand evidence of an integrated framework that manages across the entire employee lifecycle—from the initial background check to the final revocation of access.

This guide provides a practical map to implement and evidence the ISO 27001 human controls. We will show you how to move beyond basic awareness and build a defensible Human Risk Management program that satisfies ISO auditors and meets the rigorous due diligence requirements of NIS2.

Strategic FAQ: Liability & The Board's Role

Why did ISO 27001:2022 create the Annex A.6 domain?

To simplify compliance and emphasize the importance of the human element. By grouping 8 specific controls under "People," the standard highlights that technology alone cannot secure an organization without addressing human behavior.

How does NIS2 impact employee security management?

NIS2 mandates that management bodies approve cybersecurity measures and oversee their implementation. This makes the C-suite legally liable for ensuring that your ISO 27001 human controls—derived from a Clause 6.1.2 assessment—are effective, monitored, and properly evidenced.

Is a yearly training video enough for ISO 27001:2022?

No. Control A.6.3 requires education to be relevant and effective. You must provide evidence of continuous learning and behavior change (e.g., phishing simulation metrics) rather than just attendance logs.

Does the CISO carry the sole liability for human risk under NIS2?

No. NIS2 explicitly shifts accountability to the "management body" (the Board/CEO). The CISO is responsible for proposing and monitoring the strategy, but the Board is liable for approving the risk appetite and ensuring resources for controls like A.6.3.

The Foundation: How Clause 6.1.2 (Risk Assessment) Drives Your A.6 Controls

Clause 6.1.2 (Information security risk assessment) is more than an administrative formality; it is the validation mechanism that justifies every human security measure you implement. You cannot arbitrarily select ISO 27001 human controls simply because they seem like a good idea. Instead, every one of your human controls in Annex A.6 must be the direct answer to a specific risk identified during your formal Clause 6.1.2 assessment process.

Move Beyond Checklist Compliance: Use Risk to Justify Controls

Many organizations fail audits because they implement controls in a vacuum. An auditor will not ask if you have a remote work policy; they will ask why you have that specific policy.

Your answer must be rooted in data, not intuition. You are implementing these controls because your Clause 6.1.2 assessment identified a tangible threat—such as "unauthorized access via unsecured home networks"—that requires treatment. If you cannot link a human control back to a Clause 6.1.2 risk, you are merely "checking the box," which is a red flag for both ISO auditors and NIS2 regulators.

From Risk Assessment to Your Statement of Applicability (SoA)

The path from identifying a human vulnerability to proving compliance requires a systematic methodology. You must demonstrate a clear chain of custody for your decision-making.

The ISO 27001 Control Logic Flow:

1. Risk Identification (Clause 6.1.2): You identify a specific human risk (e.g., "Staff fall for CEO Fraud").
2. Risk Treatment Plan: You decide how to mitigate this risk (e.g., "We need verification protocols").
3. Control Selection (Annex A): You select the appropriate human controls (e.g., A.6.3 Awareness & A.6.8 Reporting).
4. Statement of Applicability (SoA): You formally document that these controls are active and justify their inclusion based on the initial risk.

How NIS2 Raises the Stakes for 6.1.2

Under the NIS2 Directive, the "Risk Management Approach" is Article 21. This means European regulators are now looking for the same thing as ISO auditors: proof of a thought process.

By explicitly linking your Annex A.6 controls to the risks identified in Clause 6.1.2, you are building the exact evidence of due diligence that protects the C-suite from liability. If a breach occurs, your defense is not just that you had controls, but that you had a risk-based reason for every measure you took.

Technical FAQ: Risk Assessment & Audit Logic

What happens if I implement A.6 controls without a 6.1.2 risk assessment?

You will likely receive a non-conformity during your ISO audit. The standard requires that the Statement of Applicability (SoA) is directly derived from the risk treatment process, not a generic wish list.

How does Clause 6.1.2 help with budget approval for security tools?

It translates technical needs into business risks. Instead of asking for "money for a phishing tool," 6.1.2 allows you to say, "We have identified a high-risk scenario for ransomware that requires mitigation via control A.6.3."

Can I exclude certain Annex A.6 controls?

Yes, but only if your risk assessment (6.1.2) proves that the risk is non-existent or negligible. You must document this exclusion and its justification in your Statement of Applicability.

How do we quantify "human risk" in Clause 6.1.2 without subjective guessing?

Move from qualitative ("Low/High") to quantitative data. Use metrics like "historical click rates," "departmental turnover," and "privileged access count" to calculate a risk score that justifies your A.6 control selection in the SoA.

Mapping "Before" Controls: A.6.1 (Screening) & A.6.2 (Terms of Employment)

The "Before" phase of the employee lifecycle is often the most overlooked aspect of ISO 27001 evidence. To satisfy controls A.6.1 and A.6.2 and meet your Clause 6.1.2 obligations, you must demonstrate that security due diligence begins before the employee’s first day, ensuring that every hire is verified suitable for their role and legally bound to your security policies.

A.6.1 (Screening): Policies and Evidence

Control A.6.1 mandates that background checks must be proportional to the business risk and the classification of information to be accessed. You cannot screen a receptionist and a Database Administrator with the same generic process.

Crucially, this process must remain compliant with local privacy laws like GDPR. The goal is to verify the candidate's identity, academic credentials, and professional history to prevent insider threats before they gain network access.

• Policy Needed: A formal "Background Screening Policy" defined jointly with HR.
• Evidence for Auditor: A defined matrix of screening levels based on role risk, along with redacted records showing these checks were completed prior to hiring.

A.6.2 (Terms and Conditions of Employment)

Once screened, the legal framework must be set. Control A.6.2 requires that the employment contract itself states the employee’s and the organization’s responsibilities for information security. This prevents the "I didn't know" defense during a disciplinary event.

• Policy Needed: Standardized cybersecurity clauses embedded in all offer letters or contracts.
• Evidence for Auditor: Signed contracts (or addendums for long-standing employees) that explicitly reference the Information Security Policy.

HR Pre-Employment Evidence Checklist

Use this checklist to prepare your HR department for an ISO audit:

1. Screening Policy: Documented procedure defining who gets screened and how (e.g., criminal records where legal, credit checks for finance roles).
2. Verification Logs: Anonymized records confirming checks were done (e.g., "Identity Verified: Yes | Date: MM/DD/YYYY").
3. Contract Templates: Blank copies of current contracts highlighting the specific confidentiality and security clauses.
4. Signed NDAs: Non-disclosure agreements signed prior to granting any system access.

Legal & HR FAQ: Screening & Privacy Compliance

Does ISO 27001 A.6.1 require criminal background checks for everyone?

No. The standard requires screening to be proportional to the risk. While critical infrastructure roles may require criminal checks, applying this to all staff may violate privacy laws in many European jurisdictions.

Do these controls apply to contractors and freelancers?

Yes. Anyone with access to your information assets should be subject to screening and contractual security terms (A.6.2) equivalent to their level of access, regardless of their employment status.

How do we evidence screening without violating employee privacy?

Auditors do not need to see the full background report. They need to see a "pass/fail" record or a checklist signed by HR confirming that the screening steps defined in your policy were completed.

Should we re-screen employees if they change roles internally (e.g., promotion)?

Yes. ISO 27001 implies that screening should be proportional to the new risk. If an employee moves from Marketing to a System Admin role with access to sensitive data (A.6.1), a new, deeper level of screening is required and must be evidenced.

Mapping "During" Controls (The Core): A.6.3 (Awareness) & A.6.7 (Remote Work)

The "During" phase of employment is where your security culture is rigorously tested. To satisfy ISO 27001 human controls A.6.3 and A.6.7, you must prove that security is not a one-time onboarding event, but a continuous, measured adaptation to risk. Reliance on passive consumption modules is no longer defensible evidence for critical human controls like A.6.3; auditors and NIS2 regulators now demand proof that your workforce is actively becoming a stronger line of defense.

A.6.3 (Awareness Training): The Most Critical Human Control

Control A.6.3 is the heartbeat of your defense. The 2022 standard explicitly requires that awareness, education, and training are relevant to the employee's role and kept up to date. This means a finance manager requires different training than a developer.

To achieve this, you cannot rely on ad-hoc emails. You need a structured that maps specific topics (e.g., CEO fraud, password hygiene) to specific times of the year and specific high-risk groups.

Building the Evidence for A.6.3: From Logs to KPIs

When an auditor asks, "Is your training effective?", showing them a completion certificate merely demonstrates participation, not proficiency. You must prove effectiveness.

Your evidence package should include three layers:

1. The "What" (Compliance): Logs showing who completed the modules.
2. The "Behavior" (Reality): phishing simulation KPIs that track click rates and reporting rates in real-world scenarios.
3. The "Trend" (Improvement): Executive dashboards showing improvement over time. If your click rate drops from 20% to 4% over six months, you have irrefutable evidence that control A.6.3 is effective.

A.6.7 (Remote Working): Managing the "Human Firewall" at Home

Remote work is no longer an exception; it is a primary scope of your ISMS. Control A.6.7 is a new, explicit addition to ISO 27001:2022, requiring defined rules for working outside the office.

Technology (VPNs, EDR) is only half the battle. You must evidence that employees understand the physical and behavioral rules of their home office, including the protection of printed papers and the use of personal devices (BYOD).

• Policy Needed: A formal "Remote Work Security Policy."
• Evidence: Logs proving users were trained specifically on remote risks, combined with technical logs (e.g., conditional access policies).

Case Study: Proving A.6.3 is Working

If an auditor challenges the effectiveness of your awareness program, follow this evidence flow:

1. Present the Baseline: "In January, our Clause 6.1.2 risk assessment showed a high risk of credential theft."
2. Show the Intervention: "We deployed monthly phishing simulations and role-based training modules."
3. Prove the Delta: "By June, our 'Report Phish' rate increased by 200%, and repeat offenders dropped to near zero."
4. Close the Loop: "We updated our Statement of Applicability to reflect this reduced residual risk."

Operational FAQ: Training Effectiveness & Remote Security

How often should we run phishing simulations for ISO 27001 compliance?

While the standard doesn't set a frequency, "regular" usually implies at least quarterly. However, best practice for high-risk sectors under NIS2 is often monthly to ensure behavioral retention.

Does A.6.7 require us to physically inspect employee homes?

No. That would be an invasion of privacy. Instead, you evidence compliance through "Self-Assessments" or checklists where employees attest that their workspace meets your security standards (e.g., "I have a lockable door," "I do not use public Wi-Fi without VPN").

Can we fail the audit if employees click on a phishing test?

No. Auditors know humans make mistakes. You fail if you cannot prove you are measuring that mistake rate and taking corrective action (like re-training) when it happens.

Is gamification considered valid evidence for "effective" training under A.6.3?

Yes, often better than traditional methods. If you can show that gamified leaderboards correlate with reduced phishing click rates (behavior change), auditors view this as superior evidence of engagement compared to passive video attendance.

Do we need specific training for Generative AI (ChatGPT) to comply with ISO 27001?

Yes. Since A.6.3 requires training to be "relevant," and ISO 27001:2022 includes new controls for "Data Leakage," you must evidence that employees are trained on the safe use of AI tools to prevent confidential data from being fed into public models.

Mapping "Event" Controls: A.6.8 (Reporting) & A.6.4 (Disciplinary)

Controls A.6.8 and A.6.4 represent the operational reality of your Human Risk Management program: how the organization responds during security incidents. To satisfy these ISO 27001 human controls, you must prove that your employees act as active sensors for threats and that your organization has a consistent, fair framework for addressing security negligence. It is not enough to hope employees speak up; to satisfy this human control, you must evidence a formal channel that encourages them to report "without delay," as required by your Clause 6.1.2 output.

A.6.8 (Event Reporting): Your Most Valuable Human Control

In the context of NIS2, speed is everything. Control A.6.8 is your early warning system. The standard requires a defined process for employees to flag anomalies—from a suspicious email to a lost ID badge—before they materialize into critical incidents.

If you rely on a generic "email IT" approach, you will likely fail the audit. You need a friction-free mechanism, such as a "Report Phish" button in your email client.

• Policy Needed: An "Information Security Event Reporting Procedure" that defines what to report and how.
• Evidence for Auditor: The documented procedure itself; and crucially, the logs from your helpdesk/SIEM showing employee-reported incidents. A high volume of reports is actually a positive metric for A.6.8; it proves the culture is alert.

A.6.4 (Disciplinary Process): The Fair and Formal Enforcement Framework

While A.6.8 encourages positive behavior, A.6.4 ensures accountability. This control requires a formal process to take action against employees who commit information security breaches.

Crucially, this is an HR-owned control, not just IT. The process must be graduated and proportional—you don't fire someone for one accidental click, but you might for willful data theft.

• Policy Needed: A "Disciplinary Policy" (typically within the Employee Handbook).
• Evidence for Auditor: Proof that every employee has signed/acknowledged this policy, ensuring they understand the consequences of negligence.

Event Reporting & Response Flowchart

To prove A.6.8 is functioning, document this workflow:

1. Detection: Employee notices a suspicious event (e.g., strange popup).
2. Reporting: Employee uses the designated channel (e.g., "Report Phish" button).
3. Triage: Security team analyzes the report vs. false positives.
4. Feedback: Employee receives a confirmation (Positive Reinforcement).

Incident FAQ: Culture, Reporting & Disciplinary Actions

What is the difference between a security "event" and a "weakness" in ISO 27001?

An "event" is an occurrence (e.g., receiving a phishing email). A "weakness" is a flaw (e.g., the spam filter failed to block it). Employees should be trained to report both under A.6.8.

Does A.6.4 mean we must punish employees who fail phishing tests?

Not necessarily. Best practice—and the modern view of Clause 6.1.2 risk management—suggests that "remedial training" is the appropriate first step. Formal disciplinary action is usually reserved for repeat offenders or malicious intent.

How does A.6.8 help with NIS2 compliance?

NIS2 has strict notification timelines (24/72 hours). You cannot meet these deadlines if your employees delay reporting the initial symptom. A robust A.6.8 process is the prerequisite for meeting NIS2 incident reporting obligations.

Should we allow anonymous security reporting to satisfy A.6.8?

Yes. To ensure "speed of reporting" (crucial for NIS2), removing the fear of retribution is key. Implementing an anonymous channel encourages whistleblowing on near-misses or internal policy breaches without fear of the A.6.4 disciplinary process.

Mapping "After" Controls: A.6.5 (Termination) & A.6.6 (NDAs)

Controls A.6.5 and A.6.6 manage the critical post-employment exposure window in your security perimeter identified in your 6.1.2 analysis. To satisfy these ISO 27001 human controls, you must prove that confidentiality obligations survive termination and that access rights are revoked immediately—not days later—to prevent retaliatory data exfiltration. This phase is where Clause 6.1.2 risk assessments often identify the highest potential for insider threats.

A.6.5 (Responsibilities after Termination) & A.6.6 (NDAs)

The "After" phase is strictly procedural. Control A.6.5 mandates that security responsibilities remain valid even after an employee leaves. This is legally reinforced by Control A.6.6 (Confidentiality or Non-Disclosure Agreements), which requires that the duty to protect trade secrets is explicitly defined in the contract and reiterated upon exit.

However, policies are useless without execution. You need a synchronized workflow between HR and IT to ensure off-boarding security is instantaneous. A gap of even 24 hours between an employee being fired and their access being cut is a major non-conformity.

The Evidence: The HR-IT Off-boarding Checklist

To pass an audit, you cannot just say you have a process; you must demonstrate a verifiable audit trail. The auditor will request a sample of recently terminated employees and ask for proof that their access was removed in a .

Your Evidence Checklist:

1. Notification Log: Email or ticket from HR to IT announcing the termination date before it happens.
2. IAM Revocation Timestamp: System logs proving accounts were disabled (not just deleted) at the exact termination time.
3. Asset Return Form: A document signed by the employee confirming the return of laptops, phones, and tokens.
4. Legal Reference: For complex EU terminations, ensure your process aligns with to avoid privacy disputes.

Procedural FAQ: Off-boarding & Asset Recovery

Can we rely on the original employment contract for A.6.6?

Yes, provided the original contract (A.6.2) contained a "survival clause" stating that confidentiality obligations continue indefinitely after employment ends. If not, you need a specific exit NDA.

How quickly must access be revoked for A.6.5 compliance?

"Immediately" is the standard for involuntary terminations. For voluntary resignations, it is typically done on the final hour of the final day.

Does off-boarding apply to external consultants?

Absolutely. Third-party vendors often have high-level access. You must evidence that their accounts are disabled the moment their contract expires, just like a full-time employee.

How do we handle "Bring Your Own Device" (BYOD) data during off-boarding (A.6.5)?

Your Mobile Device Policy (A.8.1) must link to your off-boarding process. You must evidence that corporate data was "containerized" and remotely wiped from the personal device upon termination, without deleting the user's personal photos or contacts.

Conclusion: Your A.6 Map is Your NIS2 Due Diligence Proof

Mapping the ISO 27001 human controls is no longer a static paperwork exercise; it is the operational foundation for a defensible security posture. By rigorously documenting your Annex A.6 implementation, you are doing more than satisfying an auditor—you are building a continuous, data-driven that directly addresses the liability concerns of the C-suite.

The evidence you generate for this Human Risk Management program—from training effectiveness logs to incident reporting KPIs—is the exact same evidence you will present to a NIS2 regulator. This alignment allows you to demonstrate "appropriate measures" and due diligence, transforming your compliance efforts from a regulatory burden into a defensive asset for your organization’s leadership.

Executive Summary FAQ: The Business Case for Compliance

‍