ISO 27001 People Controls Overview: Controls 6.1–6.8 Explained

Derek Voss's last day at Kessler Automation Group was a Friday in March. He'd been a senior DevOps engineer for four years, held privileged access to the CI/CD pipeline, customer deployment configurations, and a personal VPN certificate that let him tunnel into production from home. His manager terminated him that afternoon for a mix of performance issues and an ugly shouting match with a colleague — the kind of dismissal that happens at every mid-size company, every quarter, without incident.

Except this time the offboarding ticket sat in the IT service desk queue over a long weekend, then behind two sprint-priority incidents the following week. Eleven days passed before anyone actually revoked Derek's VPN certificate and API tokens. Nobody had told him his access still worked — he found out by accident when he tried to log into Slack out of habit and it worked too. What started as idle curiosity turned into something worse: over four days, Derek pulled proprietary source code for a client-facing automation module, copied configuration files containing customer network topology, and — in a final act of spite the Friday before his access was finally cut — deleted three months of deployment history from a backup bucket he still had write access to.

Kessler's incident response bill alone ran past $210,000: forensics, outside counsel, a breach notification to eleven affected customers, and emergency backup restoration. But the real damage showed up two months later, when their largest client — the one whose network topology had been sitting in Derek's downloads folder — declined to renew a $1.2 million annual contract, citing "concerns about the maturity of your security controls." All told, the incident cost Kessler north of $340,000 in direct spend and lost revenue, and it traced back to a single, boring failure: nobody had a documented, enforced process for what happens to a person's access the moment their employment ends. That gap is exactly what ISO 27001's Annex A People controls — 6.1 through 6.8 — exist to close.

Who this is for

This article is for ISMS implementers, HR business partners, and security leaders who need to understand the full sweep of the People controls before diving into any single one — the person building the Statement of Applicability, the HR director who's just been told "security needs your help with something called Annex A," or the consultant scoping a certification project who needs a one-page mental model of how screening, training, discipline, and offboarding connect. You'll walk away knowing what each of the eight controls requires, who owns it (HR, security, or both), what an auditor expects to see as evidence, and — critically — where the handoffs between HR and security tend to break, because that's where incidents like Kessler's happen.

The human layer, and why it's the control set auditors probe hardest

People controls are a small family — eight controls, the shortest of the four Annex A themes, wedged between the 37 Organizational controls (5.1–5.37) and the 14 Physical controls (7.1–7.14). Don't let the small number fool you. In fifteen-plus years of running ISMS implementations and sitting through certification audits, I've watched more nonconformities get raised against this theme, proportionally, than almost any other. The reason is structural: every other control theme lives primarily inside IT or facilities, where a single accountable owner can drive implementation start to finish. People controls straddle two departments that, in most organizations, have never had to build a shared process together — HR and information security — and the control fails exactly at the seam between them.

Consider the shape of the problem. Screening (6.1) happens before someone is even an employee, usually run entirely by HR or a recruiting vendor, with security having zero visibility unless someone builds a handoff. Awareness training (6.3) is jointly owned but often executes as a once-a-year compliance module nobody remembers a week later. Termination responsibilities (6.5) require HR to tell IT security, on the day someone's contract ends, that access needs to be pulled — and that notification chain is precisely where Kessler's eleven-day gap opened up. None of these are exotic technical problems. They're process and communication problems, wearing an ISO clause number.

That's also why the People controls theme punches above its weight in real-world risk. Verizon's long-running Data Breach Investigations Report and IBM's Cost of a Data Breach studies have consistently found that human-related factors — credential misuse, insider actions, social engineering, and unrevoked access — sit behind a large share of breaches, and the mechanics of an ISO 27001 assessment reflect that reality. An auditor who spends thirty minutes with your firewall change logs will spend an hour tracing a sample of leavers through your HR system, your identity provider, and your access review records, because that trail exposes whether security and HR are actually talking to each other or just filing separate paperwork.

Mapping the eight controls to the employment lifecycle

The cleanest way to hold all eight People controls in your head at once is to lay them against the employment lifecycle every person in your organization moves through: before they're hired, while they're employed, and when that employment ends or changes. ISO 27002:2022's implementation guidance groups the controls this way implicitly, and it's the framing HR teams intuitively understand, because it mirrors their own process maps.

Two things jump out once you see it laid out this way. First, the "during employment" stage carries five of the eight controls — it's where most of the ongoing security culture-building happens, and where the People theme overlaps most with the Organizational controls theme covered in the Annex A organizational controls overview. Second, control 6.5 isn't really a single event at the end of the timeline — it's a hinge. It draws on obligations set up at hiring (6.2, 6.6) and it triggers technical actions owned elsewhere in Annex A, most importantly the removal of access rights under control 5.18, which we'll come back to repeatedly in this article.

The eight People controls at a glance

Before we walk each lifecycle stage in depth, here's the full inventory in one table — useful as a quick reference when you're building your Statement of Applicability or briefing an executive who wants the ninety-second version.

A pattern worth internalizing early: almost none of these controls is "owned" by a single function in the way a firewall configuration is owned by network engineering. Every one of the eight requires HR and security to agree on a process, and most require a document that both functions can point to as authoritative. That's the design intent — Annex A People controls exist precisely because ISO 27001 recognizes that technical controls collapse if the human processes around them are informal or undocumented. We'll reference the roles and responsibilities controls, 5.2–5.4, throughout this piece, because control 5.4 (management responsibilities) is the organizational-control cousin that obligates managers — not just HR and security — to reinforce every one of these eight controls day to day. If you want the full 93-control picture this theme sits inside, PentesterWorld's Annex A — All 93 Controls at a Glance cheat sheet is a handy one-page reference to keep open alongside this article.

Stage one: pre-employment (Controls 6.1–6.2)

Everything the ISMS will eventually ask of an employee — handling sensitive data responsibly, reporting incidents, respecting access boundaries — has to be established before that person ever touches a system. Pre-employment is where you set the terms, quite literally, of the security relationship. Get it wrong here and you're retrofitting expectations onto someone who was never told about them, which is both legally shakier and practically less effective.

6.1 Screening

Screening is background verification — confirming that the person you're about to hire, contract, or grant access to is who they claim to be and doesn't carry a risk profile that's incompatible with the role. ISO 27002:2022 guidance is explicit that screening should be proportionate to the role's business requirements, the classification of information the person will access, and applicable legal and regulatory constraints — it is deliberately not a blanket "run a check on everyone for everything" mandate.

In practice, this means a receptionist and a database administrator with production access to customer PII shouldn't go through an identical screening process. The DBA role justifies deeper verification — employment history, criminal record checks where legally permitted, financial background checks for roles with fraud exposure, and confirmation of claimed qualifications — while the receptionist role might only need identity verification and standard reference checks. Getting this proportionality wrong in either direction creates problems: over-screening exposes the organization to discrimination claims and unnecessary data handling risk under GDPR and similar regimes, while under-screening for high-risk roles is exactly the gap that let Kessler's Derek Voss (whose prior employer, it turned out during the post-incident review, had quietly let him go after a similar access-related dispute) walk into a privileged engineering role with no one the wiser.

Screening also has to extend past permanent employees. Contractors, temporary staff, and third-party personnel who get access to your systems or facilities need screening commensurate with their access level — a control that trips up organizations who diligently screen full-time hires but wave contractors through because "the staffing agency handles that." Your supplier agreements, covered under the supplier relationship security controls, should explicitly require your staffing and contracting partners to perform screening equivalent to your internal standard, and you should retain evidence that they did.

"The single most common finding I raise in Stage 2 audits against control 6.1 isn't that screening didn't happen — it's that nobody can produce evidence of why a particular screening depth was chosen for a particular role. Auditors want to see a documented, risk-tiered screening policy, not just a pile of completed background check reports." — Dana Okafor, Lead ISO 27001 Auditor, Veritas Assurance Partners

A risk-tiered screening model, illustrated below, is the artifact I recommend every organization build early — it turns a vague "we screen appropriately" claim into something an auditor, and a new HR business partner, can actually apply consistently.

6.2 Terms and conditions of employment

Screening establishes who you're hiring; control 6.2 establishes what you're asking of them once hired. This control requires that employment contracts (and equivalent agreements for contractors) state each person's and the organization's information security responsibilities clearly — acceptable use expectations, confidentiality obligations, and the consequences of non-compliance, ideally cross-referenced to the acceptable use control (5.10) and your information security policies (5.1).

The failure mode I see most often isn't the absence of a security clause — most modern employment contract templates have one — it's that the clause is generic boilerplate lifted from a template five reorganizations ago, disconnected from the actual policies the ISMS now requires. An auditor tracing this control will pull a sample employee file and check whether the contract language actually points to current, controlled policy documents, not a policy that was retired two ISMS cycles back. Terms and conditions should also flag that certain obligations — confidentiality chief among them — continue after employment ends, which is the contractual thread that ties 6.2 directly to control 6.5 later in the lifecycle.

This overview covers what each pre-employment control requires at a summary level; if you're the one actually building the screening program or rewriting contract language, the dedicated deep dives on screening and background checks under control 6.1 and terms and conditions of employment under control 6.2 walk through risk-tiering methodology, legal considerations by jurisdiction, and sample policy language in far more detail than fits here.

Stage two: during employment (Controls 6.3, 6.4, 6.6, 6.7, 6.8)

This is where most of the People theme lives, and where it earns its keep day to day. Five controls sit here — building the knowledge and behavior that keeps the ISMS functioning (6.3), setting consequences for violations (6.4), formalizing confidentiality obligations (6.6), securing an increasingly common way of working (6.7), and creating the reporting culture that feeds your entire incident management program (6.8).

6.3 Information security awareness, education and training

Control 6.3 requires that personnel receive appropriate awareness, education, and training on information security, and that this happens regularly — not as a one-time onboarding checkbox. ISO 27002:2022 draws a useful three-tier distinction: awareness builds general recognition of risk and responsibility across the whole workforce; education builds deeper understanding for people whose roles carry specific security obligations; training builds the practical skill to execute a security-relevant task correctly (secure coding, incident triage, secure configuration).

Most organizations I've assessed do awareness reasonably well — an annual e-learning module, a phishing simulation program, maybe a security newsletter — and do education and training much worse. A software engineer who completes the same generic fifteen-minute awareness module as the accounts payable clerk hasn't received the secure-coding education their role actually demands. Auditors increasingly probe for role-based training differentiation, not just completion rates, and for evidence that training content gets updated when the threat landscape or the organization's own incident history changes — a phishing campaign that actually fooled twelve employees last quarter should visibly shape next quarter's training content, not disappear into a spreadsheet nobody revisits.

"We used to measure success by completion percentage — 98% of staff finished the annual module, box checked. Then we had a real spear-phishing incident that started with someone in finance who'd completed that exact module three weeks earlier. Completion rate tells you nothing about retention or behavior change. We rebuilt the whole program around quarterly micro-training and simulated phishing with real consequences tracking, and our click-through rate on simulated phishing dropped from 22% to under 4% over eighteen months." — Tom Reyes, Security Awareness Manager, Northfield Bank

6.4 Disciplinary process

Control 6.4 requires a formal, communicated disciplinary process for personnel who violate information security policy — proportionate, consistent, and applied fairly regardless of seniority. This is unambiguously an HR-owned process, but security has an essential supporting role: providing the factual, technical evidence of what happened (log records, access history, DLP alerts) that lets HR run a fair and defensible process rather than acting on hearsay.

The friction point I see constantly is timing and confidentiality. Security teams often want to move fast once they've detected a violation — pull access immediately, escalate loudly — while HR needs due process, documentation, and often union or works-council consultation depending on jurisdiction. A disciplinary process that hasn't been jointly designed by HR and security in advance means these two instincts collide in the middle of an actual incident, which is the worst possible time to be negotiating process for the first time. Well-run organizations pre-agree an escalation matrix: what triggers immediate access suspension pending investigation versus what goes through standard progressive discipline, and who has authority to make that call at 11pm on a Saturday.

6.6 Confidentiality or non-disclosure agreements

Confidentiality and non-disclosure agreements (NDAs) formalize an individual's or organization's obligation not to disclose confidential information — both during and, critically, after the relationship ends. Control 6.6 applies broadly: employees, contractors, and any third party who will be exposed to confidential information should sign an NDA appropriate to the sensitivity of what they'll see, before access is granted, not after.

The most common gap is treating the NDA as a static, one-time artifact rather than a living control. NDAs should be reviewed periodically — when the organization's confidentiality needs change (new product lines, new regulatory obligations, new categories of sensitive data), when applicable law changes, and definitely when someone moves into a role with materially different information access than the one they signed for originally. A five-year-old NDA signed by someone who was an individual contributor and is now a director with access to M&A discussions is a document that technically exists but no longer reflects the actual risk it's supposed to manage.

6.7 Remote working

Remote working requires that personnel working remotely follow appropriate measures to protect information accessed, processed, or stored outside the organization's premises. ISO 27002:2022 guidance covers physical security of the remote workspace, secure connectivity (VPN, zero-trust access), device management, and rules for family members or visitors who might have physical proximity to a work device or screen.

This control matured fast and unevenly across the industry following the pandemic-driven shift to distributed work, and I still see organizations whose remote working policy hasn't been substantively revisited since 2021 despite hybrid arrangements, digital nomad policies, and BYOD proliferation having changed the risk picture considerably since. A modern remote working control needs to address split-tunnel VPN risk, home network security baselines, coffee-shop and co-working-space use, and — increasingly — the security implications of remote staff working from jurisdictions with different data residency or legal discovery rules than where the organization is headquartered. Technical enforcement of this control leans heavily on the access control policy set out in controls 5.15–5.18, particularly identity management and authentication information, since remote work fundamentally depends on strong authentication replacing the implicit trust of a physical office perimeter.

"Remote working policy failures rarely look dramatic. It's an employee who works from a family member's laptop for a week while their own is being repaired, or someone who joins a client call from an airport lounge with a screen full of confidential pricing data facing a public walkway. None of that shows up in a log. It shows up in a client complaint, or worse, it doesn't show up at all until something's already gone wrong." — Elena Vasquez, People Operations Lead, Cascadia Biotech

6.8 Information security event reporting

Control 6.8 requires that personnel report observed or suspected information security events through appropriate channels, in a timely manner. This is deliberately broader than reporting confirmed incidents — it captures near-misses, suspicious emails, unusual system behavior, lost devices, and anything that might be a precursor to a real incident. The control's entire value depends on people feeling safe reporting, which is why it can't be designed in isolation from control 6.4's disciplinary process: if an employee who reports having clicked a phishing link gets disciplined the same way as one who deliberately exfiltrated data, you will very quickly train your workforce to stop reporting.

Event reporting is the People-controls bridge into your technical incident response machinery. A well-designed reporting channel — easy to find, fast to use, and clearly separated from formal disciplinary consequences for good-faith reports — feeds directly into the processes covered by the incident management controls, 5.24–5.28: assessment and triage (5.25), response (5.26), and the post-incident learning loop (5.27) that should, in turn, shape next quarter's awareness training under 6.3. NEW – Information Security Event Reporting: Control 6.8 is planned as a standalone deep dive covering reporting channel design, anonymized reporting options, and metrics for reporting-culture health.

For a deeper build-out of any of these five controls, see the dedicated pieces on security awareness, education, and training under control 6.3 and on disciplinary process and remote working security under controls 6.4–6.7, which cover curriculum design, escalation matrices, and technical remote-access enforcement patterns in full. Information security event reporting, control 6.8, does not yet have a standalone deep dive on PentesterWorld — it's on our backlog as a dedicated article covering reporting channel design and reporting-culture metrics in more depth than this overview allows.

Stage three: exit and change (Control 6.5)

Control 6.5 is the single control that most directly determines whether an organization ends up in a scenario like Kessler Automation Group's. It requires that information security responsibilities and duties that remain valid after termination or change of employment are defined, enforced, and communicated to the individual and, where relevant, to the organization — and it covers two distinct events people often conflate: someone leaving entirely, and someone moving internally to a different role.

Termination is the more obvious case. When employment ends — voluntarily, involuntarily, or through contract expiry — a defined process must confirm: continuing confidentiality obligations (usually surfacing what was agreed under 6.6), return of organizational assets (devices, badges, documents — this is the People-control trigger for the asset management controls covering return of assets, 5.9–5.14), and removal or modification of access rights, which is the technical execution owned by control 5.18 under the access control controls, 5.15–5.18. The People control (6.5) is the trigger and accountability mechanism; the technical control (5.18) is the execution. Kessler's failure wasn't a missing technical capability — their identity provider could have deprovisioned Derek Voss's access in minutes. It was a missing, enforced trigger: no defined SLA for how fast HR's termination notification had to reach IT security, and no automated linkage between the HR system recording his termination date and the identity system that controlled his access.

Change of employment — internal transfers, promotions, role changes — is the case organizations forget entirely. Someone moving from a customer support role into a finance role should trigger a review of their access rights just as surely as a termination does, removing access that's no longer justified by the new role, not simply adding new access on top of the old. I've audited organizations with employees holding access permissions accumulated across four internal role changes over six years, none of which were ever revoked, because "change of employment" security responsibilities were never built into the internal mobility process the way termination responsibilities eventually were.

"HR sees an internal transfer as a celebration — someone got promoted, congratulations, update the org chart. Security needs to see it as an access review trigger. Those two mental models have to coexist in the same process, and in most companies I walk into, they don't even coexist in the same meeting." — Marcus Feldman, VP of People, Solandra Health

The HR–security RACI: who actually does what

Every People control I've walked through above has two owners in some form, which in practice means it has zero owners unless someone writes down exactly who's Responsible, Accountable, Consulted, and Informed for each activity. This is the single artifact I recommend every organization build before their first internal audit against the People theme, because "HR and security both own it" is not an answer an auditor — or a frustrated employee caught between two departments giving conflicting instructions — will accept.

R = Responsible, A = Accountable, C = Consulted, I = Informed.

Two rows deserve a callout because they're where the Kessler-style failure lives: "Notify of termination/role change" and "Execute access removal on exit." Notice HR is Accountable and Responsible for the notification, but IT Operations is Responsible for execution, with security Accountable for the outcome. If those two rows aren't connected by a hard SLA — ideally an automated feed from the HR information system into the identity and access management platform — you have exactly the gap that cost Kessler $340,000. This is also where management responsibilities under control 5.4 becomes relevant: line managers, not just HR and security, are accountable for reinforcing that termination and access-removal timelines are non-negotiable, not a "get to it Monday" task.

Prioritization and sequencing: what to build first

Organizations building an ISMS from scratch, or remediating a weak People theme ahead of a certification audit, rarely have the bandwidth to stand up all eight controls simultaneously to full maturity. Sequence matters, and it should be driven by risk exposure and dependency, not alphabetical or numerical order.

This sequencing surprises people who expect awareness training to come first, since it's the most visible, most frequently discussed People control. I put it last deliberately: training is most effective when it teaches people about controls that actually exist and are enforced. Training staff on a disciplinary process that hasn't been finalized, or a reporting channel that isn't live yet, wastes the training investment and damages credibility the first time someone acts on what they learned and finds the process behind it isn't real yet.

Mapping the People controls to your Statement of Applicability

Every one of the eight People controls is a strong candidate for inclusion in almost any organization's Statement of Applicability — it's genuinely difficult to construct a defensible risk-based justification for excluding, say, screening or event reporting, since virtually every organization employs people who need some minimum verification and every organization benefits from a channel to surface security concerns. Where organizations legitimately scope or scale application is in how a control applies, not whether it applies.

The mistake I flag most often during SoA review is marking 6.7 (remote working) as "not applicable" simply because an organization doesn't have a formal remote work policy, rather than because remote access is genuinely impossible. If even one employee can VPN in from home during an outage, or a manager occasionally checks email from a personal phone, the control is applicable — the absence of a policy is the gap you need to close, not a justification for exclusion. Auditors treat "not applicable" claims on People controls with particular skepticism precisely because they're so rarely genuinely inapplicable.

Common mistakes organizations make with the People controls

Case study one: Kessler Automation Group — closing the exit gap

We opened with Kessler's $340,000 lesson. Here's how they fixed it, because the remediation is as instructive as the failure. Working with their outside ISMS consultant (me, in this narrative), Kessler's CISO Renata Ibarra and their VP of HR built a joint remediation plan in the six weeks following the incident.

"The hardest part wasn't the technical fix — connecting our HRIS termination event to an automated deprovisioning workflow in our identity provider took about three weeks of engineering time. The hardest part was rebuilding trust between HR and security. Both teams had spent years assuming the other one had this covered. Neither did." — Renata Ibarra, CISO, Kessler Automation Group

The concrete changes: Kessler implemented an automated feed from their HR information system to their identity provider, triggering same-day access suspension the moment a termination date was recorded — closing the loop control 6.5 requires and directly executing against control 5.18. They introduced a mandatory "high-risk role" flag in their HRIS for anyone with production or source-code access, which now triggers an expedited, security-reviewed offboarding checklist rather than the standard queue. And they rebuilt their disciplinary process (6.4) to explicitly document how findings from access reviews or terminations flow into it, closing the loop that let Derek Voss's prior employment dispute go unrecorded anywhere HR could see it during screening.

Eighteen months later, Kessler's average time from termination event to access revocation dropped from an unmeasured, informal "whenever IT gets to it" (the eleven-day gap in the incident) to a documented 47-minute median across 62 leaver events, verified during their surveillance audit. They passed certification with zero major nonconformities against the People theme.

Case study two: Solandra Health — the screening gap that became a breach

Solandra Health, a 340-employee behavioral health services provider, learned the cost of under-screening the hard way. A contract billing specialist, hired through a staffing agency during a hiring crunch, was granted access to patient billing records and insurance data within her first week — standard practice for the role. Nine months later, Solandra discovered she had been systematically copying patient records to a personal cloud storage account, apparently to sell identity information on secondary markets. The staffing agency's screening, it turned out, had consisted of a single reference call; Solandra had never verified what "screened" meant in their contract with the agency, and their own control 6.1 policy didn't extend explicit screening requirements to contracted staff.

"We had a beautiful screening policy on paper. It said 'all personnel' right there in black and white. Nobody had ever asked the follow-up question: does our staffing agency's definition of screening match ours? It didn't, and we found out the expensive way — breach notification to over 4,000 patients, an OCR inquiry given the HIPAA overlap, and a genuinely painful conversation with our board about why our ISO 27001 certification hadn't caught this." — Marcus Feldman, VP of People, Solandra Health

Solandra's remediation directly rewrote their supplier agreements to specify minimum screening standards matching their internal risk tiers, added an annual attestation requirement for staffing partners, and — most importantly — brought security into the vendor selection process for any staffing relationship involving access to regulated data, connecting control 6.1 explicitly to their supplier relationship security program. The total incident cost, including notification, credit monitoring for affected patients, and legal fees, exceeded $890,000 — a figure that made the case for a proportionally tiny investment in supplier screening oversight easy to justify to the board afterward.

Case study three: Cascadia Biotech — getting remote working and confidentiality right from the start

Not every People-controls story is a failure. Cascadia Biotech, a genomics research firm with a fully distributed workforce across four countries, built their People controls program during initial ISMS implementation rather than retrofitting it after an incident — and it shows in how smoothly their certification audit went.

Cascadia's People Operations Lead, Elena Vasquez, worked with security to design a tiered NDA structure (control 6.6) matched to data sensitivity — researchers with access to unpublished genomic sequencing data signed enhanced confidentiality terms with extended post-employment restrictions, reviewed by outside counsel, while general administrative staff signed standard agreements. Their remote working policy (6.7) required company-managed devices with full-disk encryption and endpoint detection for anyone accessing research data, mandatory VPN with device posture checks before connection, and an explicit prohibition on working from public co-working spaces when handling unpublished research — enforced technically, not just by policy, through conditional access rules tied into their identity provider.

"Because we're fully distributed, remote working isn't an edge case for us — it's the default. That forced us to treat control 6.7 as core infrastructure from day one instead of an afterthought policy document. When the auditor sampled our device compliance records, every single one matched policy, because the policy was enforced by the platform, not by an honor system." — Elena Vasquez, People Operations Lead, Cascadia Biotech

Cascadia's Stage 2 audit produced zero findings against the People theme and only two minor observations elsewhere in the ISMS — a result their CEO cited directly in a subsequent funding round pitch deck, since a clean ISO 27001 audit became a genuine differentiator when negotiating data-sharing agreements with pharmaceutical partners who required demonstrable confidentiality controls before sharing proprietary compound data.

Evidence checklist: what to have ready before your audit

Auditors sample the People theme by tracing individuals through the full lifecycle — pick a recent hire and follow their screening record through to a training completion log; pick a recent leaver and follow their termination through to an access-removal timestamp. Having the following artifacts organized and readily retrievable, rather than scattered across HR systems, shared drives, and individual inboxes, is the difference between a smooth sample walkthrough and a nonconformity.

How People controls compare across other frameworks

If your organization is pursuing ISO 27001 alongside other compliance obligations — common for SaaS companies serving enterprise customers, or healthcare and financial services organizations layering frameworks — it helps to recognize that the People theme has close cousins elsewhere, even though the control language and structure differ. This is worth understanding not because ISO 27001 certification substitutes for these other obligations (it doesn't, and shouldn't be positioned that way to customers or regulators), but because a well-built People controls program tends to satisfy overlapping expectations with modest incremental effort.

Positioning matters here: ISO 27001 certification demonstrates that your People controls meet an internationally recognized management-system standard, but it doesn't make you "GDPR compliant" or "HIPAA compliant" on its own — those are distinct legal obligations with their own enforcement mechanisms. What a mature People controls program does is give you a documented, auditable foundation that makes satisfying those adjacent legal requirements considerably less effort, since you're not building screening, training, and access-termination processes from scratch for each framework separately. For a refresher on terminology used across this comparison, the ISO 27001 glossary of terms defines control-language distinctions like "shall" versus "should" that matter when you're mapping requirements across standards.

People controls as a business advantage, not a paperwork exercise

The dollar figures across these three case studies illustrate a pattern I see repeated across the two hundred-plus organizations I've worked with: the cost of building People controls properly the first time is a rounding error next to the cost of an incident they would have prevented.

It's tempting to treat the People theme as the "soft" part of ISO 27001 — the eight controls that don't involve firewalls, encryption, or penetration testing, and therefore feel less consequential than the 34 Technological controls. The case studies in this article should put that instinct to rest. Kessler's $340,000 incident, Solandra's $890,000 breach, and Cascadia's board-level competitive advantage all trace back to how well — or how poorly — eight fundamentally people-and-process controls were built. No firewall configuration would have stopped Derek Voss; only a functioning termination process would have.

There's a broader strategic point here that I make to every executive team I work with: the People controls theme is where ISO 27001 implementation forces a conversation that most organizations need to have anyway and keep postponing — genuine, structured collaboration between HR and security. Organizations that build this collaboration well don't just pass audits more smoothly; they reduce insider risk, improve their ability to defend disciplinary decisions if challenged legally, and — as Cascadia found — turn demonstrable confidentiality and workforce security practices into something they can point to when negotiating with security-conscious customers and partners. Framed correctly to leadership, the People theme isn't eight compliance checkboxes. It's the business case for finally getting HR and security into the same room on a recurring basis.

If you're scoping this work now, start with the sequencing table earlier in this article, close the exit/change gap first since it carries the highest and most acute risk, and resist the temptation to build all eight controls as a paperwork exercise rather than an operational one — an auditor, and more importantly a future incident, will find the difference.

Ready to see exactly where your organization's People controls stand? PentesterWorld's ISO 27001 Gap Analysis Tool will walk you through a control-by-control readiness assessment across all four Annex A themes, and our ISO 27001 Mandatory Documents Checklist lists every document — screening policy, disciplinary process, NDA templates, and more — you'll need on hand before your Stage 1 audit. If you're still drafting your core policy suite, our Information Security Policy Template gives you a starting structure that already accounts for the cross-references People controls need into your broader policy set, and The Complete ISO 27001 Implementation Guide walks through sequencing the People theme alongside the other three control families from initial gap analysis through certification.