.svg){kind=logo}
Related Articles
No items found.
A vendor security questionnaire asks you to describe your controls for 8.16. Nobody on the team has ISO 27001 in progress. Nobody's quite sure what 8.16 even refers to, only that the number clearly comes from somewhere official.
An ISO 27002 checklist is a complete list of the 93 information security controls the standard defines, organized into four themes: organizational, people, physical, and technological. ISO 27002 itself isn't something you get certified against. It's the code-of-practice companion to ISO 27001, the one that actually explains how to implement each control rather than just listing it.
Quick answer
ISO 27002 is a non-certifiable guidance standard with 93 controls across four themes: 37 Organizational, 8 People, 14 Physical, and 34 Technological. The same 93 controls appear in ISO 27001's Annex A. Organizations certify to ISO 27001, never to ISO 27002 on its own.
That confusion is common, and reasonable. This isn't a walkthrough of ComplyJet's own ISO 27001 certification process (that's our phase-by-phase ISO 27001 checklist), and it's not the shorter side-by-side comparison of the two standards either (that's ISO 27001 vs 27002).
This is the full ISO 27002 controls catalog itself, built for anyone who needs the actual list, whether or not certification is even on the table. Getting the distinction wrong early tends to send people down the wrong article, or the wrong internal project, before they've even started.
By the end of this, you'll know exactly what each of the 93 controls covers, which 11 are new in the 2022 revision, how ISO 27002 relates to ISO 27001, and who reaches for this checklist without ever pursuing certification.
The 93-control catalog has become the default reference cited in vendor security questionnaires and internal GRC programs alike, which is exactly why having the full list in one place, rather than scattered across a paid standard and a dozen partial blog posts, actually matters.
Here's what's ahead:
- What ISO 27002 actually is, and why there's no such thing as "ISO 27002 certified"
- How it relates to ISO 27001's Annex A
- Who uses this checklist without certifying
- The four themes, and the full 93-control list inside them
- The 11 controls that are genuinely new in 2022
- How each control gets tagged with five attributes
- The mistakes teams make treating this as a box-ticking exercise
What Is the ISO 27002 Checklist? (And Why There's No ISO 27002 Certification)
ISO/IEC 27002 is a code of practice for information security controls, published by the same standards body as ISO/IEC 27001 and meant to be read alongside it. Where ISO 27001 is the certifiable management-system standard, ISO 27002 is the implementation guidance: for every control ISO 27001's Annex A lists, ISO 27002 explains what it actually looks like in practice.
There is no accredited "ISO 27002 certification." Organizations certify to ISO 27001. An external auditor tests whether your information security management system meets ISO 27001's requirements, including whether you've applied the Annex A controls relevant to your risk profile. Nobody audits a company against ISO 27002 directly, because ISO 27002 was never written as an auditable standard in the first place.
That distinction matters for two other ComplyJet articles you might land on next. Our ISO 27001 checklist walks through the phases of actually getting certified, audit and all. Our ISO 27001 vs 27002 comparison covers the conceptual difference at a higher level. This article is neither of those. It's the full controls catalog, the actual list of all 93 controls organized the way ISO 27002 itself organizes them, for readers who need the reference itself rather than a certification roadmap.
One more piece of context worth having up front: the 2022 revision reorganized everything. The 2013 edition split 114 controls across 14 domains, a structure that had grown unwieldy as some domains overlapped and others thinned out over a decade of use. The current edition condenses that into 93 controls across four themes, folding overlapping controls together and adding new ones where the 2013 edition had real gaps, which is the structure the rest of this article follows.
Both ISO 27001 and ISO 27002 are maintained by the same joint technical committee between ISO and IEC, the international bodies responsible for information security standards generally. That shared authorship is part of why the two documents line up so precisely, control for control, rather than reading like two competing takes on the same subject.
ISO 27002 vs ISO 27001: What's Actually Different
The two standards share a catalog, not a purpose. ISO 27001 is what you're assessed against: its Annex A lists 93 controls by number and name, with almost no elaboration beyond that. ISO 27002 takes that same list and, for every entry, explains the purpose, the guidance for implementing it, and additional context an auditor or implementer would actually want.
Put plainly: Annex A tells you that control 8.16 (monitoring activities) exists and is in scope. ISO 27002 tells you how to actually do monitoring activities well enough that an auditor accepts it.
Annex A's own entry for a control like this typically runs a sentence or two. ISO 27002's entry for the same control runs several paragraphs: purpose, implementation guidance, and often other information worth knowing, which is exactly the gap this article's control tables are built to close in a single scannable pass.
Do you need ISO 27002 if you already have ISO 27001? Not to certify. Annex A alone satisfies the certification requirement, and plenty of companies write their own control implementations without ever opening the ISO 27002 document itself. In practice, though, most implementers and most auditors treat ISO 27002 as the default reference for what "satisfying" a given Annex A control actually requires, since Annex A's own descriptions are deliberately brief.
Note
Same 93 controls, same numbering (5.1 to 5.37, 6.1 to 6.8, 7.1 to 7.14, 8.1 to 8.34), in both standards. ISO 27001's Annex A is the list you're audited against. ISO 27002 is the explanation of how to actually meet each item on that list.
If your decision is really just about understanding the two standards side by side, rather than working through the full control catalog, our ISO 27001 vs 27002 comparison covers that ground more directly.
Who Needs the ISO 27002 Controls Checklist Without Pursuing Certification
Certification isn't the only reason to open this list. Three situations come up constantly where the ISO 27002 controls checklist matters on its own, with no ISO 27001 audit anywhere in the plan, and each one treats the 93 controls as a working reference rather than a certification milestone.
Vendor Security Questionnaires
Enterprise procurement teams have started citing ISO 27002 control numbers directly in security questionnaires, even when the vendor being assessed isn't ISO 27001 certified at all. "Describe your controls for 8.9" is a real question now, and having the control catalog on hand turns that from a scramble into a lookup. Answering with the actual control name and a specific implementation detail reads as far more credible than a vague paragraph about "strong security practices."
Picture the actual exchange: a security reviewer emails a spreadsheet with control numbers down one column and a blank column next to it for your response. Someone on the team pastes "8.9" into a search bar, gets nothing useful back, and starts guessing.
Pulling up this table instead turns that same request into a two-minute lookup: control 8.9 is configuration management, so the answer is a short, specific paragraph about how baseline configurations are defined, tracked, and enforced, not a vague reassurance about "following best practices."
GRC Controls-Mapping Programs
Internal security and GRC teams often adopt ISO 27002's 93 controls as their program's baseline taxonomy, independent of any certification decision. It's a comprehensive, well-maintained reference, which makes it a reasonable foundation for an internal controls library even when nobody's pursuing an audit.
Building a program around a recognized taxonomy also makes it easier to explain coverage to a board or a customer later, since it maps to something external and citable rather than an internal spreadsheet nobody outside the security team has ever seen.
A GRC platform or internal risk register built this way also ages better. New hires and new tools can be mapped against a stable, externally maintained list instead of a homegrown taxonomy that only the person who built it fully understands, which matters the moment that person leaves or moves to a different team.
Benchmarking Other Frameworks Against ISO 27002 Controls
Mapping SOC 2's Trust Services Criteria, or NIST CSF's five functions, against ISO 27002 controls is a common way to find real coverage gaps between frameworks a company already holds. The controls list works as a shared reference point precisely because it's this granular, letting a team see exactly which specific control a broader framework's criterion actually maps to, rather than comparing two frameworks at the level of vague category names.
This matters most for a company holding multiple certifications at once. A SOC 2 and ISO 27001 shop, for instance, can use the 93-control catalog as the common language between two audits that otherwise use entirely different vocabularies, cutting down on duplicate evidence requests from two separate auditors asking about the same underlying control in different words.
Most of the ISO 27002 questions we actually see aren't from companies pursuing ISO 27001. They're from teams that got asked a specific control number in a vendor questionnaire and needed to know what it meant fast. — Upendra Varma, CTO at ComplyJet
ISO 27002 Four Themes and the 93 Controls Inside Them
The 2022 edition organizes every one of the ISO/IEC 27002:2022 information security controls into one of four themes. Each control also gets an ID (the theme's leading digit plus a sequential number) so it can be referenced precisely, the same 8.16-style shorthand a vendor questionnaire might use.
| Theme | Clause | Controls | What It Covers |
|---|---|---|---|
| Organizational | Clause 5 | 37 (5.1-5.37) | Policies, roles, supplier relationships, incident management, business continuity, compliance |
| People | Clause 6 | 8 (6.1-6.8) | Screening, employment terms, training, disciplinary process, remote working |
| Physical | Clause 7 | 14 (7.1-7.14) | Perimeters, entry control, equipment protection, secure disposal |
| Technological | Clause 8 | 34 (8.1-8.34) | Access control, cryptography, secure development, network security, monitoring |
That's the full 93-control breakdown: 37 plus 8 plus 14 plus 34. Every one of them sits in exactly one theme, replacing the 2013 edition's 14 separate domains.
Organizational Controls on the ISO 27002 Checklist (Clause 5, 37 Controls)
The largest theme by control count, covering the governance layer: information security policy, roles and responsibilities, supplier relationships, incident management, business continuity, and legal/regulatory compliance. If a control is about how the organization runs information security rather than a specific technical or physical safeguard, it lives here. A mid-size SaaS company usually finds this the theme with the most existing artifacts already in place, since policies and supplier contracts tend to predate any formal ISO work.
People Controls (Clause 6, 8 Controls)
The smallest theme, and the one most directly about individual behavior: screening before hiring, security awareness training, what happens at termination, remote-working expectations, and how employees report a security event when they spot one. Small as it is, auditors weight it heavily, since most real incidents trace back to a person, not a missing technical safeguard.
Physical Controls (Clause 7, 14 Controls)
Everything about the physical environment: securing office space and server rooms, protecting equipment from environmental threats, controlling entry, and disposing of hardware and storage media securely once it's retired. Fully remote companies sometimes assume this theme doesn't apply to them, but it still covers home-office equipment handling and secure disposal of any hardware employees are issued.
Technological Controls on the ISO 27002 Checklist (Clause 8, 34 Controls)
The largest technical surface area: access control, cryptography, secure software development, network security, logging and monitoring, malware protection, and data leakage prevention. This is the theme most vendor security questionnaires draw from most heavily, and the one where a specific tool or configuration is usually the actual evidence an auditor wants to see.
The Full ISO 27002 Checklist: All 93 Controls by Theme
This is the genuinely complete ISO 27002 controls list, organized exactly the way the standard organizes it: all 93 controls, one row each, grouped by theme, with enough detail in each row to actually be useful rather than just a name repeated back. Treat it as the ISO 27002 controls spreadsheet you'd otherwise have to build yourself, no gated download required.
This ISO 27002 list of controls and the ISO 27002 93 controls breakdown above are numbered identically, so you can jump straight from a theme summary to any individual control below.
Organizational Controls (37)
These 37 run from 5.1 (information security policy) to 5.37 (documented operating procedures), and lean on documentation, ownership, and process rather than a specific device or technology.
| Control | Name | What It Covers |
|---|---|---|
| 5.1 | Policies for information security | A top-level policy set, approved by management, communicated to staff, and reviewed on a set schedule |
| 5.2 | Information security roles and responsibilities | Named owners for every security decision and task, not a shared, ambiguous responsibility |
| 5.3 | Segregation of duties | No single person controls a sensitive task end to end without a second set of eyes |
| 5.4 | Management responsibilities | Managers actively enforce security practices with their own teams, not just point to a policy document |
| 5.5 | Contact with authorities | A defined process and named contact for engaging law enforcement or regulators when needed |
| 5.6 | Contact with special interest groups | Staying connected to security forums and professional associations to track emerging risks |
| 5.7 | Threat intelligence | Actively collecting and analyzing information about emerging threats relevant to the organization |
| 5.8 | Information security in project management | Security requirements built into every project's plan from kickoff, not bolted on afterward |
| 5.9 | Inventory of information and other associated assets | A maintained, accurate record of what assets exist, where, and who owns each one |
| 5.10 | Acceptable use of information and other associated assets | Clear, enforced rules for how assets can and can't be used by staff |
| 5.11 | Return of assets | A defined process ensuring assets come back when employment or a contract ends |
| 5.12 | Classification of information | Information labeled by sensitivity, with handling rules that follow the classification automatically |
| 5.13 | Labelling of information | Classification labels applied consistently and visibly across documents and systems |
| 5.14 | Information transfer | Defined rules for moving information securely, both inside the organization and to outside parties |
| 5.15 | Access control | The overarching policy governing who can access what, and on what basis |
| 5.16 | Identity management | Managing the full lifecycle of a user identity, from creation through deactivation |
| 5.17 | Authentication information | Secure handling of passwords and other credentials, including how they're issued and reset |
| 5.18 | Access rights | Granting, periodically reviewing, and promptly revoking access rights as roles change |
| 5.19 | Information security in supplier relationships | Security expectations built into vendor relationships before any data is shared |
| 5.20 | Addressing information security within supplier agreements | Security terms written directly into supplier contracts, not left as a verbal understanding |
| 5.21 | Managing information security in the ICT supply chain | Extending security requirements down through the supply chain, not just to a direct vendor |
| 5.22 | Monitoring, review and change management of supplier services | Ongoing oversight of supplier performance and any changes to their service |
| 5.23 | Information security for use of cloud services | A defined process for securely acquiring, configuring, and using cloud services |
| 5.24 | Information security incident management planning and preparation | A documented, rehearsed plan for handling incidents before one actually happens |
| 5.25 | Assessment and decision on information security events | A clear process for triaging events into confirmed incidents worth escalating |
| 5.26 | Response to information security incidents | A defined, tested incident response procedure that people actually know how to follow |
| 5.27 | Learning from information security incidents | Feeding incident findings back into prevention, so the same failure doesn't repeat |
| 5.28 | Collection of evidence | Preserving evidence correctly and defensibly for investigations or potential legal use |
| 5.29 | Information security during disruption | Maintaining core security controls even during a crisis, outage, or disaster |
| 5.30 | ICT readiness for business continuity | ICT systems specifically planned and tested to support the broader business continuity plan |
| 5.31 | Legal, statutory, regulatory and contractual requirements | Actively tracking and meeting every applicable legal and contractual obligation |
| 5.32 | Intellectual property rights | Protecting the organization's own IP and respecting others' in how information is handled |
| 5.33 | Protection of records | Records kept accurate, available, and protected from loss, tampering, or premature deletion |
| 5.34 | Privacy and protection of PII | Handling personal data in line with applicable privacy law, not just internal policy |
| 5.35 | Independent review of information security | Periodic review of the whole security program by a genuinely independent party |
| 5.36 | Compliance with policies, rules and standards for information security | Ongoing checks confirming internal policy is actually being followed, not just documented |
| 5.37 | Documented operating procedures | Operating procedures written down clearly, not left as unwritten tribal knowledge |
The organizational table above runs the longest of the four, which tracks with it being the largest theme by control count. The people table below is deliberately the shortest, just eight rows, but auditors rarely treat it as the least important one.
People Controls (8)
All eight run from pre-hire screening at 6.1 to event reporting at 6.8, with training, discipline, and remote-work expectations sitting in between.
| Control | Name | What It Covers |
|---|---|---|
| 6.1 | Screening | Background checks appropriate to the role's risk level, done before hiring, not after |
| 6.2 | Terms and conditions of employment | Security responsibilities stated explicitly in employment terms, not assumed or implied |
| 6.3 | Information security awareness, education and training | Ongoing security training tailored to role, not a one-time onboarding checkbox |
| 6.4 | Disciplinary process | A formal, consistently applied process for handling policy violations |
| 6.5 | Responsibilities after termination or change of employment | Security obligations, like confidentiality, that continue after someone leaves or changes roles |
| 6.6 | Confidentiality or non-disclosure agreements | NDAs that actually reflect the organization's real confidentiality needs, reviewed periodically |
| 6.7 | Remote working | Security requirements specific to working outside a controlled office environment |
| 6.8 | Information security event reporting | A clear, well-known channel for any employee to report a suspected event fast |
Physical controls come next, and they're worth reading even for a fully remote team. The table below still applies to home-office equipment and any hardware issued to staff, not just a leased office space.
Physical Controls (14)
The 14 move roughly from perimeter and entry (7.1-7.4) through environmental and workspace safeguards (7.5-7.9) to equipment and media handling (7.10-7.14).
| Control | Name | What It Covers |
|---|---|---|
| 7.1 | Physical security perimeters | Defined, protected physical boundaries around sensitive areas and equipment |
| 7.2 | Physical entry | Controlling, and logging, exactly who enters secure areas and when |
| 7.3 | Securing offices, rooms and facilities | Physical security calibrated to each space's actual sensitivity level |
| 7.4 | Physical security monitoring | Continuous surveillance of premises to catch unauthorized access as it happens |
| 7.5 | Protecting against physical and environmental threats | Safeguards against fire, flood, and similar environmental risks to facilities |
| 7.6 | Working in secure areas | Specific rules for behavior and access once inside a designated secure area |
| 7.7 | Clear desk and clear screen | No sensitive information left visible on a desk or an unlocked screen |
| 7.8 | Equipment siting and protection | Equipment placed and protected in ways that reduce risk, damage, and opportunistic access |
| 7.9 | Security of assets off-premises | Protecting laptops and media once they physically leave the building |
| 7.10 | Storage media | Secure handling of storage media through its entire lifecycle, including disposal |
| 7.11 | Supporting utilities | Power, cooling, and similar utilities protected from failure that could disrupt operations |
| 7.12 | Cabling security | Power and data cabling protected from interception, tampering, or physical damage |
| 7.13 | Equipment maintenance | Maintenance performed correctly and on schedule to preserve availability and integrity |
| 7.14 | Secure disposal or re-use of equipment | Data verifiably wiped before any equipment is disposed of or reused elsewhere |
The technological table is the largest of the four after organizational controls, and the one most vendor questionnaires and security reviewers draw from directly, since it's where the concrete tooling and configuration evidence tends to live.
Technological Controls (34)
The 34 cluster loosely into access and identity (8.1-8.5), day-to-day secure operations and monitoring (8.6-8.24), and secure development (8.25-8.34), the last of which is the single densest stretch in the whole catalog.
| Control | Name | What It Covers |
|---|---|---|
| 8.1 | User endpoint devices | Security requirements for laptops, phones, and similar devices staff actually use |
| 8.2 | Privileged access rights | Extra scrutiny, approval, and restriction on any admin-level access |
| 8.3 | Information access restriction | Access limited strictly to what a given role actually needs to do its job |
| 8.4 | Access to source code | Source code access tightly controlled, logged, and reviewed for anomalies |
| 8.5 | Secure authentication | Authentication methods strong enough for the risk level of what's being accessed |
| 8.6 | Capacity management | Actively monitoring and planning for resource capacity before it becomes a problem |
| 8.7 | Protection against malware | Layered defenses against malicious software across endpoints and infrastructure |
| 8.8 | Management of technical vulnerabilities | Identifying and remediating vulnerabilities on a defined, tracked timeline |
| 8.9 | Configuration management | Secure baseline configurations defined, tracked, and enforced across systems |
| 8.10 | Information deletion | Information actually deleted, not just archived, once it's no longer needed |
| 8.11 | Data masking | Sensitive data obscured wherever full visibility isn't genuinely required |
| 8.12 | Data leakage prevention | Controls that actively catch sensitive data leaving where it shouldn't |
| 8.13 | Information backup | Backups taken on schedule, tested regularly, and proven actually restorable |
| 8.14 | Redundancy of information processing facilities | Enough built-in redundancy to meet the organization's actual availability requirements |
| 8.15 | Logging | Security-relevant events logged consistently across systems, not selectively |
| 8.16 | Monitoring activities | Logs and systems actively watched in near real time, not just collected and archived |
| 8.17 | Clock synchronization | System clocks kept synchronized so logs across systems can actually be correlated |
| 8.18 | Use of privileged utility programs | Powerful system utilities restricted to specific people and monitored closely |
| 8.19 | Installation of software on operational systems | A controlled, approved process for what software gets installed where |
| 8.20 | Networks security | Networks segmented, monitored, and protected appropriately for what they carry |
| 8.21 | Security of network services | Security requirements explicitly defined for every network service in use |
| 8.22 | Segregation of networks | Sensitive network segments isolated from general and less-trusted traffic |
| 8.23 | Web filtering | Access to malicious or clearly inappropriate websites actively restricted |
| 8.24 | Use of cryptography | Cryptographic controls applied appropriately, consistently, and with proper key management |
| 8.25 | Secure development lifecycle | Security built into every phase of software development, not added at the end |
| 8.26 | Application security requirements | Security requirements defined before an application is built, not retrofitted after |
| 8.27 | Secure system architecture and engineering principles | Systems architected with security principles baked in from the earliest design decisions |
| 8.28 | Secure coding | Coding practices that deliberately avoid common, well-documented vulnerability classes |
| 8.29 | Security testing in development and acceptance | Security testing built directly into the development and release pipeline |
| 8.30 | Outsourced development | Security requirements extended fully to any outsourced development work |
| 8.31 | Separation of development, test and production environments | Environments kept genuinely separate to limit accidental or malicious impact |
| 8.32 | Change management | Changes to systems reviewed, approved, and controlled before they go live |
| 8.33 | Test information | Test data handled with the same care and access controls as production data |
| 8.34 | Protection of information systems during audit and testing | Audit and testing activities carried out so they don't themselves create new risk |
Certification-track readers working through this same list phase by phase, with audit prep folded in, will find that version in our ISO 27001 checklist.
The 11 New Controls in the 2022 ISO 27002 Checklist Update
Eleven controls are genuinely new in the 2022 edition, not renamed or merged versions of something from 2013. Each one reflects a security practice that simply wasn't mainstream, or wasn't distinct enough to warrant its own control, back in 2013. The 2013 edition's ISO 27002 security controls set had no dedicated entry for cloud adoption, active threat intelligence, or secure-by-design development at anywhere near the scale organizations operate at today.
| Control | Name | Why It's New |
|---|---|---|
| 5.7 | Threat intelligence | Formalizes threat-intel gathering as its own practice, not an implicit part of monitoring |
| 5.23 | Information security for use of cloud services | Cloud adoption is now the default architecture, not an exception needing separate justification |
| 5.30 | ICT readiness for business continuity | Separates ICT-specific continuity planning from general business continuity planning |
| 7.4 | Physical security monitoring | Recognizes active surveillance as its own distinct physical control, not a byproduct of entry control |
| 8.9 | Configuration management | Configuration drift is now treated as a named, tracked risk rather than an afterthought |
| 8.10 | Information deletion | Deletion gets its own control, separate from retention and classification decisions |
| 8.11 | Data masking | Reflects wider, routine use of masked data across non-production environments |
| 8.12 | Data leakage prevention | DLP tooling has matured enough as a category to warrant its own dedicated control |
| 8.16 | Monitoring activities | Active, ongoing monitoring, distinct from the more passive logging control |
| 8.23 | Web filtering | A distinct, widely deployed technical control in its own right, not folded into malware protection |
| 8.28 | Secure coding | Secure-by-design development is now an expected baseline, not an aspirational extra |
None of these are replacements. The other 82 controls are consolidated and renamed versions of the 2013 edition's 114, condensed down as duplicates and overlaps got merged into single, cleaner entries. These 11 are pure additions, and they're the cleanest signal of where the standard's authors saw the biggest gaps in 2013's coverage: cloud, threat intelligence, and secure software development.
A vendor questionnaire or auditor referencing any of these 11 by number is a reasonably reliable signal that they're working from the current 2022 edition rather than an outdated 2013 copy, which is a useful, quick sanity check in its own right.
The Five Control Attributes Behind Every ISO 27002 Checklist Entry
Beyond the 93-control list itself, ISO 27002:2022 introduced a tagging system: five attribute categories, and every single control carries a value for each one. These aren't extra requirements. They're a way to slice the same 93 controls into custom views without touching the underlying list.
Control type tells you whether a control is preventive, meaning it stops an incident before it starts, detective, meaning it catches one already in progress, or corrective, meaning it fixes things after the fact. Operational capabilities map a control to the practical security domain it supports in day-to-day work, like asset management or human resource security. Security domains group controls into governance, protection, defense, or resilience. Cybersecurity concepts align each control to one of the widely used identify, protect, detect, respond, or recover functions. Information security properties flag which of confidentiality, integrity, or availability the control primarily protects.
| Attribute | What It Captures |
|---|---|
| Control type | Preventive, detective, or corrective |
| Operational capabilities | The practical security domain the control supports (e.g. governance, asset management) |
| Security domains | Governance, protection, defense, or resilience |
| Cybersecurity concepts | Aligned to identify, protect, detect, respond, or recover |
| Information security properties | Confidentiality, integrity, or availability |
Take control 8.16, monitoring activities, as a worked example. It's tagged detective (control type), it maps to detection and resilience (security domains), it aligns to the detect function (cybersecurity concepts), and it primarily supports confidentiality and integrity (information security properties). None of that changes what the control requires. It changes how you can report on it: pull every detective control across all 93, or every control mapped to the detect function, without re-reading the whole list line by line.
Pro tip
Use the attributes when you need a role-specific or domain-specific view: every technological-theme, detective-type control for a SOC review, for instance. Reading the full 93-control list top to bottom is rarely how anyone actually works with it day to day.
Common Mistakes to Avoid While Going through the ISO 27002 Audit Checklist
Most of these come from treating the 93 controls as a flat box-ticking exercise instead of a risk-based reference. The Statement of Applicability, the document that records which controls actually apply and why, is where most of these mistakes either get caught early or slip through unnoticed until an auditor or a customer's security team asks a pointed question about a control that was quietly skipped.
- Applying all 93 controls regardless of actual risk. ISO 27002 itself expects applicability to follow a risk assessment and Statement of Applicability, not a blanket "implement everything" approach that wastes effort on controls that don't fit the business.
- Assuming ISO 27002 compliance is a claimable status. There's no "ISO 27002 certified" designation. Only ISO 27001 certification exists, and claiming otherwise in a sales conversation or on a website is a credibility risk waiting to be called out.
- Using 2013-edition domain names when a 2022-aware questionnaire expects theme language. "Domain 9" doesn't mean anything to someone asking about "the technological theme," and mixing the two vocabularies mid-conversation reads as sloppy.
- Skipping the control attributes entirely, then struggling later to produce a domain-specific or function-specific view when a customer or auditor asks for one on short notice.
- Not documenting why a control was marked not applicable. That justification is exactly what an auditor or GRC reviewer asks for first, and "we didn't think about it" isn't a defensible answer in a review.
- Treating the checklist as a one-time exercise. Controls, and their applicability, need periodic review as the business, its architecture, and its risk profile change over time.
- Confusing control numbering between the 2013 and 2022 editions. A vendor questionnaire citing "A.12.4.1" is using 2013 numbering; the equivalent 2022 control is 8.15, logging, and mapping between the two matters more than most teams expect.
- Relying on a single, stale mapping document long after a system change. A controls-mapping spreadsheet built during initial implementation and never revisited stops reflecting reality the moment infrastructure, vendors, or headcount change, which is exactly when an auditor's questions expose the gap.
How ComplyJet Fits Into Your ISO 27002 Controls Work
ISO 27002 isn't listed as its own framework on ComplyJet's frameworks page, and that's intentional: it isn't independently certifiable, so there's nothing to build a standalone product around. What ComplyJet does automate is the same control catalog through its ISO 27001 program, tracking evidence and control status for the identical 93 controls covered in this article, whichever theme they fall under.
If the reason you're here is that you're actually planning to certify to ISO 27001 rather than just needing the reference list, that's the program this maps to directly. That includes helping map existing evidence, from access reviews to vendor contracts, directly against the same control numbers this article walks through, so a team doesn't have to translate between an internal spreadsheet and the standard's own numbering by hand.
For teams that landed here purely for the reference table and aren't pursuing certification at all, there's no pressure to engage with any of this. The 93-control catalog above works the same whether or not ComplyJet, or any other vendor, is ever involved.
ISO 27001
Same 93 controls, tracked automatically instead of manually
ComplyJet maps evidence collection directly to the ISO 27002 control catalog covered above, for teams pursuing ISO 27001 certification, priced flat per company rather than per seat.
FAQs
What Is ISO 27002?
ISO/IEC 27002 is a code-of-practice standard providing detailed implementation guidance for information security controls. It's published alongside ISO/IEC 27001 and shares the same 93-control catalog, but it isn't itself an auditable or certifiable standard. Think of it as the practical handbook that sits next to the certifiable rulebook.
Is ISO 27002 Certifiable?
No. Organizations get certified to ISO 27001, which includes the Annex A control list. ISO 27002 is the non-certifiable guidance companion explaining how to implement those same controls. There's no such thing as being "ISO 27002 certified," no matter how thoroughly a company has adopted the standard's guidance internally.
How Many Controls Are on the ISO 27002 Checklist?
93 controls, split across four themes: 37 Organizational, 8 People, 14 Physical, and 34 Technological. That's down from 114 controls across 14 domains in the 2013 edition, with 11 genuinely new controls added along the way.
What Are the Four Themes in ISO 27002?
Organizational, People, Physical, and Technological. They replaced the 2013 edition's 14 separate domains, consolidating overlapping controls in the process and giving every control exactly one home.
What's the Difference Between ISO 27001 and ISO 27002?
ISO 27001 is the certifiable management-system standard, the one you're actually audited against, including its Annex A control list. ISO 27002 is the non-certifiable guidance standard explaining how to implement each of those same controls in practice, with far more detail than Annex A's brief entries provide.
Do You Need the ISO 27002 Checklist If You Already Have ISO 27001?
Not to certify. Annex A alone satisfies the certification requirement. In practice, though, most implementers and auditors use ISO 27002 as the standard reference for what actually satisfying a given control looks like, since Annex A's own descriptions are brief by design and leave a lot of practical judgment to the reader.
Is There an ISO 27002 Checklist PDF?
ISO doesn't offer the standard itself as a free PDF; it's a paid publication available directly from ISO or a national standards body. This article's full 93-control table above is built to serve the same practical need: a complete, organized list in one place, without a download or a gate in the way. Bookmarking this page tends to work better in practice than a static PDF anyway, since the table stays easy to search and update as ComplyJet keeps it current.
Does ISO 27002 Apply Only to Companies Pursuing ISO 27001?
No. That's the misconception this article opened with. Vendor security teams, internal GRC programs, and companies benchmarking other frameworks all use the ISO 27002 controls checklist directly, with no ISO 27001 certification anywhere in the picture. If nothing else sticks from this article, that's the one distinction worth remembering before opening any vendor questionnaire, GRC tool, or framework-mapping spreadsheet that references a control number from this list.
Related Reading
- ISO 27001 vs 27002, for the shorter conceptual comparison between the two standards.
- ISO 27001 Checklist, for the phase-by-phase certification walkthrough if you're actually pursuing ISO 27001.
- ISO 27001 Domains, for readers still working with 2013-edition domain terminology.
- ISO 27701 Guide, for the privacy-information-management extension of the same ISO 27000 family.
The full 93-control table above is the fastest way back to any specific control number referenced elsewhere in this article.
