📌 For non-technical readers.
If you’re an expert: it’s simplified, but still practical.
Ever seen a “security spreadsheet” where everything’s green… but nothing actually happens?
That’s security theater: looking safe without reducing real risk. 🎭
ISO/IEC 27002 can be a powerful guide—or a massive time sink.
The difference is one word: context.
Here’s what you’ll get: how 27002 really works, when it helps, when it doesn’t, and how to implement controls that actually operate.
The basics: what ISO/IEC 27002 is (no fluff)
ISO/IEC 27002 is a catalog of information security controls.
Think “menu,” not “recipe.”
It’s not certifiable by itself.
ISO/IEC 27001 is the one tied to certification because it requires an ISMS and operational evidence.
The 2022 edition reorganized the catalog into 4 themes with 93 controls.
The 2013 edition had 114 controls and a different structure. 📊
The 4 themes are:
- Organizational (governance and how work gets done)
- People (culture and employee lifecycle)
- Physical (spaces and equipment)
- Technological (logical and technical controls)
27002 explains what controls exist and what they’re meant to achieve.
It doesn’t tell you which tool to buy, how often to run the process, or who must own it.
That’s on you—and your context: risk, business needs, constraints, and obligations.
The real problem: when 27002 turns into theater
Theater looks like this:
A document says “implemented,” but nobody runs the control day to day.
It usually happens because:
- Controls are picked “because the standard says so,” not because risk demands it.
- IT gets stuck owning everything, while Legal, HR, Procurement, and Ops stay out.
- People confuse documentation with operation.
End result: pretty PDFs, weak resilience.
Classic example: “we have backups.” 🟢
Do you test restores? Do you track RTO/RPO? Do you have evidence?
If not, backups are hope—not a control.
Another one: “we have a firewall.” 🟡
Firewall = the bouncer at the door: without rules and monitoring, it’s just a suit.
And the biggest myth: “we passed the audit, so we’re secure.”
Compliance isn’t immunity; it’s structured risk management.
How 27002 works in practice: the control chain
27002 works when you treat it as building blocks for risk treatment.
Not as a flat checklist.
A control should be tied to five things:
- The risk it addresses
- The control objective (what changes)
- An owner (role-based)
- Evidence (how you prove it runs)
- A metric (how you know it’s effective)
Miss one, and the control becomes decoration.
Simple mental model:
Risk → objective → control → operation → evidence → improvement
This is where the SoA shows up. 🔴
SoA (Statement of Applicability) is where you justify what applies, what doesn’t, and how it’s implemented.
If your SoA says “everything applies” without real analysis, that’s a red flag.
When 27002 helps (depending on your size)
Small orgs (10–50, no security team):
It’s a reality check. It helps you spot what the market expects before a big customer asks.
Example 1 (fintech startup):
To land a bank deal, you’ll need basics: access controls, passwords, 🟡MFA, and backups.
You won’t implement all 93 controls—you’ll pick what protects the business.
Mid-size orgs (100–500, lean IT/security):
It helps you formalize what’s already “tribal knowledge.”
“What Bob remembers” becomes a repeatable process with evidence.
Example 2 (regional SaaS company):
User offboarding depends on someone’s memory.
27002 pushes ownership, timelines, and auditable records.
Large orgs (500+ with subsidiaries):
It becomes a shared language for baselines and maturity comparisons.
Example 3 (multi-country group):
Same controls, different realities.
27002 standardizes expectations and evidence across units.
When it won’t help (and you should say it)
If leadership won’t commit, it won’t work.
Many controls require executive decisions and ongoing funding.
It’s also not a “fast certification” trick.
27002 isn’t certifiable; and rushing 27001 without operational controls is how you buy a certificate and keep the risk.
And it won’t replace technical judgment.
The standard won’t decide your crypto choices, architectures, or hardening approach.
If your operations are chaotic (high churn, constant tool swaps, no ownership), 27002 becomes makeup on a moving target.
Where 27002 fits with other frameworks and regulations
27002 is often used to implement the controls that support an ISMS 🔴 (Information Security Management System).
It also maps well to:
- GDPR (appropriate technical and organizational measures)
- PCI-DSS (payment-specific requirements)
- HIPAA (health data requirements in the U.S.)
- NIST CSF (Identify, Protect, Detect, Respond, Recover)
- CIS Controls (clear technical prioritization)
Practical take:
Use NIST CSF for strategic structure.
Use 27002 for tactical control selection and implementation detail.
Use CIS when you need “do these first” technical guidance.
A practical 7-step implementation method
Step 1: define a defendable scope
Scope = which processes, systems, sites, and data are in.
If you claim “everything” but cover only central IT, you’ll get exposed.
Deliverable: a map of crown jewels (critical assets).
Step 2: build risk scenarios
Don’t create an endless threat list.
Create scenarios: asset + threat + vulnerability + impact.
15–30 strong scenarios beat 200 generic ones.
Step 3: turn risks into measurable objectives
“Improve monitoring” is vague.
“Detect anomalous admin access in <X> minutes” is real.
Step 4: select controls as components
This is where 27002 shines.
Choose controls because they achieve an objective—not because they fill a row in Excel.
Step 5: write a technical SoA
“Not applicable” isn’t a justification.
Use: out of scope, risk accepted, equivalent control, compensating control.
Step 6: design operational evidence
Strong evidence: tickets, logs, reports, reviews, test results.
Weak evidence: pretty PDFs with no records.
Step 7: measure and improve
Pick a small set of KPIs that actually drive decisions.
Examples: critical vuln fix time, privileged 🟡MFA coverage, backup restore success rate.
Best practices that actually move the needle
✅ Start with well-run basics
🟢password manager, 🟢MFA, 🟢tested backups, 🟢patching, 🟢asset inventory.
✅ Assign owners per control (RACI)
If “security owns everything,” nobody really owns it.
✅ Automate evidence where possible
Central logs and ticketing outlive screenshots.
✅ Review access on a schedule
Monthly for privileged access, quarterly for general access (adjust to risk).
✅ Don’t ignore vendors
Contracts without verification are wishful thinking.
✅ Run realistic drills
Awareness isn’t a once-a-year talk.
Phishing simulations and incident exercises reveal the truth.
✅ Test restores
If you’ve never restored, you don’t know your recovery plan works.
Common mistakes (and quick fixes)
❌ “Everything applies” SoA
Fix: prioritize by risk and scope, justify each decision.
❌ Copy-paste policies
Fix: short, operable policies with owners and frequency.
❌ Tool = control
Buying DLP/EDR/SIEM 🟡 doesn’t mean you operate them.
Fix: define use cases, coverage, alerting, and review cadence.
❌ Measuring “completion,” not effectiveness
Fix: KPIs + testing + corrective actions.
❌ On-prem thinking in a SaaS reality
Fix: focus on identity, configuration, logging, and vendor risk in cloud/SaaS.
Mini cases: situation → solution → outcome
Case A (mid-size, 250 employees):
Situation: slow offboarding, ex-staff keeps access.
Solution: HR-triggered workflow + tickets + monthly privileged review.
Outcome: fewer orphan accounts and cleaner audits.
Case B (startup, 35 employees):
Situation: shared creds in chat.
Solution: 🟢password manager + 🟡MFA + secret rotation.
Outcome: reduced leak risk and faster onboarding.
Case C (enterprise group):
Situation: every subsidiary does security “their way.”
Solution: 27002 baseline + comparable metrics.
Outcome: visibility, prioritization, and budget you can defend.
Closing
27002 isn’t magic.
It’s a strong control catalog—if you connect controls to risk, owners, evidence, and metrics.
Key takeaways:
- Don’t implement controls for the checklist—do it for context.
- A “real” control leaves logs, metrics, and continuous improvement.
- Audits stop being theater when operations are verifiable.
💬 Follow
📖 vvc-consultor.com
Hashtags: #Cybersecurity #InfoSec #ISO27001 #RiskManagement #vvcconsultor