richardk/iso27diy-corp
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Initial commit

Browse source
This commit is contained in:
Richard Kranendonk 2026-04-19 15:29:42 +02:00
commit 570d74d4dd
67 changed files with 4609 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

9
Drafts and Ideas/About/About the Industry.md Normal file
View file

@ -0,0 +1,9 @@
This next part is about the iso 27001 industry and its actors. Correct the following text so that the proper terms are used. Expand with other actors and their roles if necessary. This is the text:
- the standards organization develops the standard for a certain domain
- the certification bureau checks if the standard is properly implemented within the organization and issues a certificate
- Clients, regulatory bodies and other stakeholders of the organization demand the organization to be certified to proof adequate risk control within the domain
- the organization implements the standard to get certified
- the implementation consultant helps the organization to implement the standard
- the internal auditor checks if the standard is properly implemented within the organization
- The external auditor works for the certification bureau

28
Drafts and Ideas/About/About the flow.md Normal file
View file

@ -0,0 +1,28 @@
---
tags:
- project/iso27DIY/journey
- type/explainer
---
## Journey
We’ll start with analyzing the context of where the ISMS will operate. We’ll look at your organization, it’s structure and processes, important stakeholders and internal and external developments.
From that we’ll help you identify risks and opportunities, and define risk mitigating measures.
Together we will create policies, procedures and guidelines, and control implementation plans.
Gradually, we’ll work towards your first internal audit.
++ increased understanding
++ actually improving your security posture
We know that we need to get your organization along, so we’ll start with risks and opportunities that matter to your stakeholders.
## Timeline
we will adapt to your pace, but we will actively coach you, like your sports watch would.
## Interaction model
Work iteratively, you can always come back later

0
Drafts and Ideas/About/Essence of the ISMS.md Normal file
View file

21
Drafts and Ideas/About/Interactie met de gebruiker.md Normal file
View file

@ -0,0 +1,21 @@
# Interactie met de gebruiker
1. Gebruiker kiest een Lesmodule uit menu
2. Content wordt getoond. Filmpje, tekst, afbeelding.
3. De gebruiker krijgt een ‘taak’. Hij/zij heeft de keuze die nu uit te voeren, of te parkeren in de persoonlijke Takenlijst[^1] (onderdeel van GRC). De taak bevat een verwijzing naar de content, zodat die later weer opgepakt kan worden.
4. De taak kan bestaan uit bijv:
5. het uploaden van een document
6. het invullen van een vragenlijst
7. het vullen van een tabel (simpele spreadsheet met rij/kolom totalen bijv)
8. Wat de gebruiker toevoegt wordt opgeslagen in de GRC-module
9. De input van de gebruiker wordt gebruikt om nieuwe content te genereren, bijv. een beleidsdocument. Dit kan gebeuren met templates, logische regels, of LLM.
10. Gegenereerde content wordt ter controle aangeboden aan de gebruiker. Die moet daar wijzigingen in aan kunnen brengen en uiteindelijk de productie akkoord verklaren.
11. Na akkoord is er een wijziging in het ‘volwassenheidsniveau’ van het ISMS. Deze komt tot uitdrukking in het ‘Implementatie Dashboard’ (onderdeel van GRC). – kan dynamisch gegenereerd worden
- [ ] Uitwerken: Er zit onderlinge afhankelijkheid in: soms kun je stap 3 pas nemen als je stap 1 gedaan.
- [ ] Volwassenheidsniveaus benoemen.
[^1]: in een latere versie kunnen taken toegewezen worden aan een andere gebruiker.

417
Drafts and Ideas/About/Ocean Sailing Metaphor.md Normal file
View file

@ -0,0 +1,417 @@
# The Merchant Vessel's Voyage: An ISMS Implementation Story
## **The Premise**
You're the captain of a merchant trading vessel, transporting valuable cargo across established trade routes. Your mission: deliver precious goods safely to distant ports while building a reputation for reliability and security that will sustain your trading company for years to come.
---
## **Episode 1: Charting the Destination** (Setting the Goals)
Before leaving port, you gather your officers and backers around the navigation table. What defines success for this voyage?
- **The cargo's safe arrival**: Your hold contains valuable spices, silk, medical herbs, fine instruments - goods that merchants await
- **The crew's safe return**: A ship without seasoned sailors is just expensive timber
- **Maintaining your reputation**: In the trading world, trust is currency
- **Regulatory compliance**: You must satisfy the Harbor Master's requirements and international maritime codes to operate legally
- **Sustainable operations**: This isn't a single voyage - you're building a trading enterprise
You define your **scope**: Which routes will you sail? Which ports are included? What cargo types will you carry?
Your **security objectives** become clear: confidentiality (cargo manifests and trade secrets), integrity (goods arrive uncontaminated and authentic), availability (reliable delivery schedules).
You announce these goals to all stakeholders - the ship's owners, the crew, the merchants whose goods you carry.
---
## **Episode 2: Reading the Waters** (External Issues)
Before you can plan your route, you must understand the world through which you'll sail:
- **Pirate activity**: Which waters are most dangerous? What are their tactics? Are they after cargo, ransom, or the ship itself?
- **Weather patterns**: Monsoon seasons, hurricane zones, fog-prone straits
- **Geopolitical tensions**: Which nations are at war? Where are trade embargoes? Which flags grant safe passage where?
- **Port regulations**: Different harbors have different requirements - quarantine rules, inspection protocols, docking fees
- **Competition**: Other trading companies, their routes, their security measures
- **Technology changes**: New navigation instruments, faster ships, encrypted communication methods between trading houses
- **Economic conditions**: Which goods are in demand? Where are prices best?
You gather intelligence from:
- Harbor masters' reports
- Returning captains' debriefings
- Maritime insurance underwriters
- Coastal watchtowers' signals
- Trading guild bulletins
This **external context** shapes every decision you'll make.
---
## **Episode 3: Knowing Your Vessel** (Internal Issues, Assets, Strengths & Weaknesses)
Now you turn your attention inward. What are you working with?
### **Your Assets to Protect:**
- **The cargo** (your primary information assets): Spices in the forward hold, medicinal herbs requiring cool storage, sealed letters of credit, navigation charts showing profitable routes
- **The ship itself**: Hull integrity, sail condition, water-tightness of hatches
- **Your crew**: The navigator's expertise, the surgeon's knowledge, the carpenter's skills
- **Your reputation and relationships**: Trust with merchants, favorable insurance rates, preferential port access
- **Supporting systems**: The ship's boat (your backup), fresh water supplies, repair materials
### **Strengths:**
- Experienced first mate who's sailed these waters for 20 years
- Recently reinforced hull
- Disciplined crew with low turnover
- Strong relationships with key ports
### **Weaknesses:**
- The navigator is brilliant but aging, with no clear successor trained
- Your encryption methods for sensitive documents are known by former crew who now sail for competitors
- The starboard cargo hold has a persistent leak
- Only two crew members can operate the new navigational instruments
- Your emergency procedures exist mostly in the captain's head
You conduct a thorough **inventory and assessment**: Who has access to what? Where are critical vulnerabilities? What depends on single points of failure?
---
## **Episode 4: Mapping the Dangers** (Risk Assessment)
With your destination set, external conditions understood, and internal capabilities assessed, you now systematically identify what could go wrong:
### **Risk Identification:**
- **Pirates in the Straits of Malacca**: High likelihood, severe impact (loss of cargo and possible crew)
- **Storm season in the South China Sea**: Medium likelihood, catastrophic impact
- **Crew illness/scurvy**: Medium likelihood, major impact on operations
- **Cargo contamination from hold leak**: High likelihood, moderate impact
- **Navigator incapacitation**: Low likelihood, severe impact
- **Insider threat** (disgruntled crew revealing routes to competitors): Low likelihood, moderate impact
- **Port authority seizure** due to paperwork errors: Medium likelihood, major impact
- **Fire in the cargo hold**: Low likelihood, catastrophic impact
### **Risk Analysis:**
For each risk, you assess:
- **Likelihood**: Based on historical data (ships lost in these waters), current intelligence (pirate activity reports), ship conditions (that leaky hold)
- **Impact**: What happens if this occurs? Loss of cargo value? Crew lives? Ship itself? Reputation damage?
- **Existing controls**: What are you already doing? You have fire buckets, a daily inspection routine, experienced crew
### **Risk Evaluation:**
You plot these on a risk matrix with your officers. Which risks are acceptable for a merchant vessel? Your risk appetite is moderate - you're not running military secrets that require extreme measures, but you can't afford frequent losses either.
You prioritize: High likelihood + high impact risks must be addressed immediately. Low likelihood + low impact risks you'll accept.
---
## **Episode 5: Plotting the Course** (Risk Treatment - Identifying Measures)
For each significant risk, you now decide your strategy:
### **Avoid:**
- **Don't sail during peak storm season**: Delay departure by three weeks
- **Avoid notorious pirate waters entirely**: Take the longer, safer route
### **Reduce:**
- **Pirate encounters**: Sail in convoy with other merchants, hire additional armed crew, reinforce the captain's cabin (where valuables are stored), establish communication signals between convoy ships
- **Cargo contamination**: Repair the hold leak, use sealed containers, implement daily inspection rounds
- **Navigation failure**: Train two junior officers in advanced navigation, maintain duplicate charts stored separately, establish position verification protocols
- **Fire**: Implement strict rules about open flames, station fire watch, conduct monthly fire drills, store water barrels strategically
### **Transfer:**
- **Cargo loss**: Purchase maritime insurance (though it's expensive and has limitations)
- **Crew injury**: Contract with a maritime medical service in major ports
### **Accept:**
- **Minor cargo spoilage**: Some loss of spice potency is inevitable over long voyages; build this into pricing
- **Wear on sails and rigging**: Routine deterioration; maintain replacement supplies
You create a **Statement of Applicability** - essentially a ship's security manifest that lists all maritime security controls, which ones you're implementing, which you're not, and why.
---
## **Episode 6: The Ship's Standing Orders** (Policies and Procedures)
Now you formalize how your ship will operate. These aren't just the captain's whims - they're documented protocols that ensure consistency even when you're sleeping:
### **Access Control Policy** ("Who Goes Where"):
- **Cargo holds**: Only the quartermaster and captain have keys; entry logged in the ship's book
- **Captain's cabin** (sensitive documents): Captain only; first mate has sealed emergency key
- **Navigation room**: Navigator and trained officers only
- **Critical supplies** (medical stores, emergency rations): Surgeon and quartermaster access; usage logged
### **Watch Standing Procedures** (Continuous Monitoring):
- Four-hour watches with clear handoff protocols
- What to look for: other ships, weather changes, coastal landmarks
- How to sound alarms for different threats
- Night signal procedures
### **Cargo Handling Protocols**:
- Inspection upon loading (verify against manifest)
- Daily hold inspections (check for water, pests, shifting)
- Verification before unloading (ensure seals intact)
- Chain of custody documentation
### **Emergency Response Procedures**:
- **Fire**: Specific roles assigned, equipment locations, communication signals
- **Pirate attack**: Battle stations, valuable cargo disposal procedures (if necessary), surrender signals (if absolutely necessary)
- **Man overboard**: Stop signals, rescue boat launch, recovery procedures
- **Taking on water**: Damage assessment, pumping priorities, emergency port protocols
### **Navigation Protocols**:
- Position verification twice daily
- Cross-checking between celestial navigation and known landmarks
- Backup navigation methods
- How to handle disagreement between navigator and captain
### **Communication Security**:
- How to encode sensitive messages
- Which information can be shared in port
- Procedures when crew members depart
- How to verify identity of ships claiming to be friendly
### **Maintenance Standards**:
- Daily inspections (rigging, hull, pumps)
- Weekly maintenance (sail repairs, deck treatment)
- Monthly drills (fire, abandon ship, battle)
- Equipment testing schedules
### **Crew Management**:
- Hiring procedures (background checks with previous captains)
- Security training for new crew
- Disciplinary procedures
- Departure protocols (what they can take, what they must return)
Each policy answers: **What** must be done, **Why** it matters, **Who** is responsible, **When** and **How** it's done, and **What to do if** something goes wrong.
---
## **Episode 7: Casting Off** (Implementation)
The planning is complete. Now comes the actual voyage - putting your measures into action:
### **Pre-Departure:**
- Reinforce the cargo hold (that leak must be fixed)
- Install the new secure storage in the captain's cabin
- Conduct security training for the crew on the new protocols
- Brief all hands on the voyage plan and their roles
- Load cargo with new inspection procedures
- Verify all equipment is aboard and functional
### **Underway:**
- The watch rotation begins according to standing orders
- Daily hold inspections reveal the repairs are holding
- You drill the crew on emergency procedures weekly
- Navigation protocols are followed - the junior officers are learning
- Access logs are maintained for all sensitive areas
- Incident reports are filed when protocols aren't followed (the cook accessed medical supplies without the surgeon present - why? turns out for a legitimate minor burn, but the procedure needs clarification)
### **Continuous Adjustment:**
- Three days out, you receive signals that pirates have been sighted ahead; you adjust course and increase watches
- A storm forces you to secure cargo differently than planned - you document the new method
- One crew member proves unreliable at watch; they're reassigned and additional training provided to their replacement
Implementation means **living** the procedures daily, not just having them written down.
---
## **Episode 8: Keeping the Ship Supplied** (Resources and Competence)
A ship doesn't sail on good intentions. Throughout the voyage, you must ensure:
### **Financial Resources:**
- Budget for unexpected port fees
- Reserve funds for emergency repairs
- Insurance premiums
- Crew wages (security depends on crew loyalty)
### **Human Resources:**
- Adequate crew size for watch rotations
- Specialized skills: navigator, surgeon, carpenter, sailmaker
- Training time - you can't expect new crew to know complex procedures instantly
- Succession planning - you're actively training that junior navigator
### **Physical Resources:**
- Spare rigging and sails
- Repair materials (timber, pitch, nails)
- Security equipment (weapons, locks, sealing wax)
- Safety equipment (fire buckets, rescue lines, ship's boat)
- Extra supplies beyond minimum (because delays happen)
### **Knowledge Resources:**
- Navigation charts (and backups)
- Ship's library of maritime procedures
- Current intelligence from ports
- Documentation of your own procedures and lessons learned
### **Time:**
- Adequate voyage timeline (rushing leads to cutting security corners)
- Maintenance windows (you must occasionally heave-to for repairs)
- Training time during long passages
- Rest for crew (exhausted sailors make mistakes)
You establish **competence requirements**: What must each role know? The first mate must be able to take command. The quartermaster must know cargo handling. All crew must know basic emergency procedures.
You track **awareness**: Does everyone understand why these security measures matter? They'll follow procedures better if they understand they're protecting their own interests (cargo arrives = they get paid; ship is safe = they live).
---
## **Episode 9: The Ship's Log** (Documentation)
From the moment you leave port, you maintain meticulous records. In the maritime world, if it's not in the log, it didn't happen:
### **The Master Log:**
- Daily entries: position, weather, course, significant events
- All decisions and why they were made
- All incidents and how they were handled
- Changes to procedures
### **Specialized Logs:**
- **Cargo manifest**: What's aboard, where it's stored, condition checks
- **Watch log**: Who was on duty when, what they observed
- **Maintenance log**: Repairs, inspections, equipment status
- **Incident reports**: Anything unusual, even if minor
- **Training records**: Who's been trained on what procedures
- **Access logs**: Who entered sensitive areas when
### **Charts and Plans:**
- Navigation charts with your actual route (vs. planned)
- Cargo stowage plans
- Emergency evacuation plans
- Crew roster with roles and competencies
### **Why This Matters:**
- **Learning**: What worked? What didn't? Your next voyage will be safer
- **Accountability**: If something goes wrong, you can trace what happened
- **Compliance**: Port authorities and insurers require documentation
- **Continuity**: If you're incapacitated, your first mate needs to know everything
- **Evidence**: If crew or cargo disputes arise, you have records
- **Improvement**: You can't improve what you don't measure
The ship's log is your organizational memory - it outlasts any single voyage.
---
## **Episode 10: Harbor Master's Inspection** (Audit and Review)
### **Internal Reviews (Ongoing):**
Throughout the voyage, you conduct regular self-assessments:
- **Daily bridge briefings**: What happened in the last 24 hours? What's ahead? Are procedures being followed?
- **Weekly officer meetings**: Deeper review of security effectiveness, crew morale, equipment status
- **Incident reviews**: Whenever something goes wrong (or almost goes wrong), you gather the relevant crew and analyze: What happened? Why? What will we do differently?
- **Monthly drills**: Testing emergency procedures and evaluating performance
### **Port Audits (External):**
When you reach port, several inspections occur:
**Harbor Master's Security Inspection:**
- Are your cargo manifests accurate?
- Are dangerous goods properly stored and documented?
- Does your crew have proper credentials?
- Are your safety and security measures adequate?
- Do you meet international maritime security codes?
The Harbor Master is like your ISO 27001 auditor - they verify you're following established maritime security standards.
**Cargo Survey:**
- Merchants' representatives inspect their goods
- Verifying seals are intact
- Checking condition matches manifest
- This proves your controls worked (or reveals where they didn't)
**Insurance Assessment:**
- Your insurer may inspect to verify you followed security protocols
- This affects future premiums and coverage
### **Post-Voyage Review (Management Review):**
After reaching your destination, you conduct a comprehensive review with your officers and the ship's owners:
**What Worked:**
- The convoy strategy - no pirate encounters despite sailing through risky waters
- Junior navigator training - you now have backup capability
- Daily hold inspections caught problems early
**What Didn't:**
- The new watch rotation led to gaps in dawn coverage twice
- Access logging was inconsistently followed (people got busy)
- Fire drill times were too slow - crew needs more practice
**Metrics Analysis:**
- Incidents logged: 12 (down from 18 last voyage)
- Security procedure compliance: 94% (target was 95%)
- Cargo loss: 0.5% (within acceptable range)
- On-time arrival: 2 days early (good)
- Crew injuries: 1 minor (excellent)
**Risk Reassessment:**
- Are the risks you identified still accurate?
- Did new risks emerge? (You encountered fog banks that weren't in your initial assessment)
- Have external conditions changed? (Political tensions have eased in certain waters)
- Are your controls still appropriate?
**Decisions for Next Voyage:**
- Adjust watch rotation based on lessons learned
- Implement new access control procedure to improve compliance
- Conduct more frequent fire drills
- Update risk assessment to include fog navigation
- Invest in better equipment for certain controls
### **Continuous Improvement:**
The voyage doesn't truly end when you reach port. You've learned from this journey, updated your procedures, and you're already preparing for the next departure. The ship's standing orders are now revised - Version 2.0 - incorporating everything you've learned.
You share lessons with other captains in your trading company. Best practices spread through the fleet.
**ISO Certification Parallel:** This comprehensive review - with documented evidence from your logs, demonstrated effectiveness of controls, and commitment to continuous improvement - is what convinces the Harbor Master (auditor) to certify your ship as meeting international security standards. The certificate isn't the end goal; it's recognition that you operate a secure, reliable, continuously improving operation.
---
## **The Journey Continues**
Unlike a fortress that, once built, stands static, your merchant vessel is always in motion. The sea changes. Threats evolve. Crews turn over. New ports open. Technology advances.
Your ISMS is the same - not a project with an end, but an operational discipline. The standing orders (policies) guide daily operations. The log (documentation) captures your organizational memory. The crew (your people) execute with competence and awareness. The inspections (audits) verify effectiveness. And the voyage (your business) continues, safer and more resilient because of the system you've built.
**The ISO 27001 certificate is your Letter of Marque** - official recognition that your vessel meets the standards required to trade safely in international waters, protecting the valuable cargo (information) entrusted to your care.

37
Drafts and Ideas/About/iso27DYI - How this works.md Normal file
View file

@ -0,0 +1,37 @@
# iso27DYI: How this works
## Structure
We've divided the ISMS implementation into a number of Episodes.
- setting the goals
- what's the lay of the land (relevant external issues)
- how's our equipe, our assets that need to be protected (internal issues, strengths and weaknesses)
- knowing the risks
- identifying measures to mitigate the risks
- creating the recipes (policies) for resilience in different areas / domains
- implementing the risk mitigating measures
- ensuring resources to implement and maintain everything
- all the while documenting stuff as we go allong
- audit and review how we're doing.
For every element of the ISO 27001 you need to be able to tell the auditor:
- what your method is for implementing the requirement
- how and when you monitor the results of your implementation
- how and when you evaluate the results and identify possible improvements
- when you are planning to implement these improvements
- who's involved and who's responsible for each of these steps.
In ISO27DIY we deal with this by providing Policy Cards for every Clause and Control of the ISO 27001.
There's always our Controls Library with everything in Plain English, support by our consultants. When the time is ready, you can plan a preliminiary audit.
## Principles
- work with what you got - keep doing what you do but make it 'compliant'
- work iteratively - you can always come back later
# Metadata
- which 'slots' this scene fills

38
Drafts and Ideas/Context, Strategy, and Leadership/Sources for the Context sessions.md Normal file
View file

@ -0,0 +1,38 @@
# Sources for the Context sessions
## PECB Lead Auditor Training
[[PECB 27001 LA S05 E01a - Context of the organization]]
## Sparks
[[The ISMS in its context]]
[[Context analysis]]
## Mark I content
[[ISO27DIY Video A.4 Context and Scope - Internal issues]]
[[ISO27DIY Video A.2 Context and Scope - Stakeholders]]
[[ISO27DIY Video A.3 Context and Scope - Regulations and Contracts]]
## Standard
[[ISO_27001_2022_4.1_MoC Understanding the organization and its context]]
[[ISO_27001_2022_4.2_MoC Understanding the needs and expectations of interested parties]]
[[ISO_27001_2022_4.3_MoC Determining the scope of the information security management system]]
[[ISO_27001_2022_4.4_MoC Information security management system]]
## From the 'canvas'
Besturingsmodel (4.1)
Functiehuis (4.1)
Organogram (4.1)
Bedrijfsprocessen (4.1)
SWOT (4.1)
- [[SWOT Analyses template]]
DESTEP (4.2)
Stakeholder analyse (4.2)
Wet- en regelgeving (4.2, A5.31-A5.34)
## Further research
- [ ] Assets?
- [ ] Impactbepaling uit [[Dataclassificatie Humankind]]

7
Drafts and Ideas/Context, Strategy, and Leadership/The ISMS in its context.md Normal file
View file

@ -0,0 +1,7 @@
# The ISMS in its context
The primary purpose of the ISMS is to Control information security risks, that may impede on the organization achieving its goals.
The ISMS does not exist in a vacuum. It interacts with the internal and external context of the organization. 
An effective ISMS relies on a relationship between / the interplay of organizational goals, its context, threats and risks to the CIA of information, and available resources.

30
Drafts and Ideas/Controls/Create a threat analysis chatbot.md Normal file
View file

@ -0,0 +1,30 @@
---
tags:
- llm
---
[Source](https://www.linkedin.com/posts/mbundgaard_cyber-threat-landscape-analysis-activity-7274406690442149888-Pf-X), retrieved 20-12-24
Create your own cyber threat analysis GenAI chatbot in 30 minutes.
Free of cost and code.
1) Don't waste your time manually collecting every report from different websites behind forms. Go to [Jacob Wilson](https://www.linkedin.com/in/jacobdjwilson/)'s [github repo](https://github.com/jacobdjwilson/awesome-annual-security-reports/tree/main/) that's updated with all relevant and current reports.
2) Don't waste time reading through 20-40 reports that are almost identical. Instead, upload them to [notebooklm.google.com](http://notebooklm.google.com/) and let AI do the heavy lifting.
3) Remember to upload/link to your infosec taxonomy. I recommend [VERISframework.org](https://verisframework.org) as it is used by Cyentia Institute and Verizon.
4) Don't use any old GPT. Prompt your notebook to get actual references and prevent hallucinations.
5) Don't return to the same sources with annotation and manual review. Instead, write and adjust prompts to your specific purposes.
You now have your very own reliable cyber threat chat bot to help your analyze any problem.
**Prompt suggestion:**
`Context: Doing an annual analysis of the threat landscape surrounding a specific enterprise.`
`The enterprise is a [region][industry][services] company. It has around [number] employees and annual revenue of [your annual revenue].`
`Please provide a two-part analysis:`
1. `A summary of the relevant industry research. The summary must adhere to the [taxonomy] framework. Each section must include examples from the source material and/or statistics such as forecasting or historical changes.`
2. `A list of the 5-10 most relevant threat scenarios to be included in a subsequent risk assessment. Provide the scenarios in a table format. The table must include the following columns [column 1], [column 2], [column 3] [etc] and strictly adhere to [taxonomy).`
For columns I suggest Threat actor, activity and attribute.

9
Drafts and Ideas/ISMS/About implementation and proof.md Normal file
View file

@ -0,0 +1,9 @@
---
tags:
- project/iso27DIY
- type/explainer
---
The auditor will require proof of the implementation of the ISMS and all it’s individual controls. Proper implementation means a control is risk-based, there’s a policy describing the why and how of it’s implementation, it’s results are monitored or measured, it’s effectiveness is evaluated, and possible improvements to the implementation of the control are identified.

63
Drafts and Ideas/ISMS/About policies controls and risks.md Normal file
View file

@ -0,0 +1,63 @@
---
tags:
- iso27001
- policy
- control
- risk
---
`Within a ISO 27001 compliant ISMS, is it possible to implement a control without having a policy for that control?`
`Claude Sonnet 4:`
In an ISO 27001 compliant ISMS, implementing a control without having a policy for that control is technically possible but not recommended and may create compliance issues.
Here’s why this creates problems:
**Policy Requirements**: ISO 27001 requires documented information for information security policies, and Annex A controls often reference the need for established policies. The standard expects that controls should be guided by appropriate policies that define the organization’s approach and requirements.
**Documentation and Evidence**: During certification audits, auditors will look for evidence that controls are properly governed. A control implemented without supporting policy documentation may be seen as ad hoc or insufficiently managed, potentially leading to non-conformities.
**Control Effectiveness**: Policies provide the framework for consistent implementation and operation of controls. Without them, you risk:
- Inconsistent application across the organization
- Lack of clear responsibilities and accountabilities
- Difficulty in measuring effectiveness
- Challenges in maintaining the control over time
**Best Practice Approach**: The recommended structure is:
1. **Policy** - High-level statement of intent and requirements
2. **Procedures** - Detailed steps for implementation
3. **Controls** - Actual security measures and technical implementations
4. **Records** - Evidence of operation and effectiveness
While you might temporarily operate a control without formal policy documentation, you should establish the appropriate policy framework to ensure long-term compliance and effectiveness. This approach aligns with ISO 27001’s emphasis on a systematic, risk-based approach to information security management.​​​​​​​​​​​​​​​​
`Does each control need an associated risk?`
`Claude Sonnet 4:`
No, each control does not need an associated risk in an ISO 27001 compliant ISMS. This is a common misconception about how the risk-based approach works.
**How Risk and Controls Actually Relate:**
**Risk-Driven Control Selection**: Controls should be selected based on your risk assessment outcomes. You identify risks, evaluate them, and then select controls to treat those risks. However, the relationship is typically many-to-many:
- One risk may require multiple controls to adequately treat it
- One control may address multiple different risks
- Some controls may be implemented for compliance or operational reasons beyond specific risk treatment
(so far, so good …)
(if you interpret the following as: specific to your organization, there’s a point somewhere)
**Baseline Controls**: Organizations often implement baseline security controls (like basic access controls, antivirus, firewalls) that address general security risks rather than being tied to specific identified risks (???). These are considered good security hygiene.
**Compliance-Driven Controls**: Some controls may be implemented to meet regulatory requirements, contractual obligations, or industry standards, even if they don’t directly correspond to a specific risk you’ve identified in your risk assessment.
**Control Objectives**: What’s important is that your overall control framework addresses your identified risks and supports your risk treatment decisions. The traceability should be at the risk treatment level, not necessarily at the individual control level.
**Documentation Expectations**: Your ISMS documentation should demonstrate how your control selection relates to your risk assessment and treatment decisions, but this doesn’t require a one-to-one mapping of every control to a specific risk.
The key is ensuring your control selection is justified and supports your overall risk management strategy, whether through direct risk treatment, baseline security posture, or compliance requirements.​​​​​​​​​​​​​​​​

17
Drafts and Ideas/ISMS/About the Statement of Applicability.md Normal file
View file

@ -0,0 +1,17 @@
---
tags:
- project/iso27DIY
- type/explainer
---
## About the Statement of Applicability
In essence, the Statement of Applicability shows the outcome of the risk treatment process ([[ISO_27001_2022_6.1.3_MoC Information security risk treatment|6.1.3a]]). It is usually presented as a table of Annex A controls, together with a short explanation for the selection *or* exclusion of each, and its implementation status.
This follows directly from [[ISO_27001_2022_6.1.3_MoC Information security risk treatment|Clause 6.1.3d]], that demands that the Statement of Applicability contains:
* the controls that are **necessary** to implement the chosen risk treatments, including the rationale for their selection
* the **status** of their implementation *("whether the necessary controls are implemented or not")*
* the reason for exclusion of any and all other controls from Annex A.
Though ISO 27002 offers guidelines for the implementation of the controls from Annex, the organization is free in their design. The organization is also free to identify them "from any source", so you could also include controls from for instance XXX or YYY.
One is generally advised to "Comply or Explain", which means you implement *all* controls from Annex A in some form, or you explain why you don't need to, based on your risk analysis and chosen risk treatment.

290
Drafts and Ideas/Measures vs Workability.md Normal file
View file

@ -0,0 +1,290 @@
# Measures vs Workability: least privilege, need-to-know
*Hypothesis: security frameworks promote least privilege and need-to-know for access control, while common data‑classification schemes and real‑world practices frequently result in minimal or inconsistent protective measures until incidents or regulations force stricter controls.*
What is least privilege, need-to-know. and why is it important?
- The least privilege principle us defined as giving users only the access they need to perform their job, explicitly to reduce attack surface and limit damage if accounts are compromised.
- Excessive permissions and broad access are repeatedly identified as drivers of breaches in cloud environments, where over‑privileged accounts magnify the blast radius of attacks, underscoring how least‑privilege is supposed to be a maximally conservative control principle, not a minimal one.
- Security organizations and vendors explicitly promote least‑privilege and need‑to‑know as foundational, proactive principles to minimize risk.
- Because of cost‑effective management, scalability, and operational efficiency, organizations choose to reserve stronger measures for only the highest sensitivity classes, and apply only baseline controls to the classes.
- Implementations often rely on subjective, user‑driven decisions about how to classify information, which is acknowledged as inconsistent and prone to human error; this can lead to sensitive data being misclassified and not receiving appropriate protection until problems are discovered.
- Cloud‑security analyses highlight misconfigurations and overly permissive identity and access management as primary causes of data breaches, showing that data is frequently more exposed than its intended classification or policy would suggest, especially when default or “internal” classifications are used with weak enforcement.
- Studies and policy critiques of government secrecy note pervasive over‑classification of documents, which paradoxically strains controls and leads to mishandling and inconsistent protection because staff cannot realistically maintain high‑grade measures for everything labeled sensitive.
- This dynamic supports the idea that classification is often used in a coarse, administrative way, with either over‑broad “classified” labels or broad “internal/public” buckets, and the actual security measures tend to converge on what is minimally workable in practice rather than what the maxim of least privilege would prescribe.
- data‑classification guidance and breach analyses show that: lower classes are defined to warrant minimal controls, classification is inconsistently applied, and misconfigurations and over‑privileged access remain dominant breach causes—together indicating that classification outcomes often default to minimal measures unless regulatory or incident pressure requires more.
*Hypothesis: the least privilege tends to be implemented more rigorously and systematically for technical/admin roles than for access to business information.*
- Modern Privileged Access Management (PAM) practices are explicitly built around least‑privilege: discover all privileged accounts, strip rights down to the minimum, enforce just‑in‑time elevation, and avoid privilege creep.
- Vendors and best‑practice guides describe mature patterns such as time‑bound admin elevation, granular role‑based admin roles, session recording, and centralized approval workflows, which directly optimize and monitor admin rights rather than leaving them broadly assigned.
## Persistent over‑privilege for business data
- Data‑centric security and DSPM literature repeatedly stresses that over‑privileged access to business data (files, SaaS content, analytics datasets) is widespread, with the majority of granted permissions unused and many of them high‑risk.[2]
- Case studies for SaaS data protection highlight “internal overexposure” as a primary issue: collaborative tools make it easy to share information widely, while security teams lack visibility to enforce “need to know” on everyday business documents, HR data, and customer information.[4][2]
## Indicators that least privilege is better enforced on IT/admin side
- PAM guidance calls least privilege “fundamental” and prescribes concrete control patterns (role‑based admin levels, just‑in‑time access, automatic revocation, monitoring) that are often implemented as dedicated tools and processes for admin accounts.[6][1][3]
- Insider‑threat and privilege‑risk reports emphasize reducing privileged admin accounts and entitlement sprawl as key risk‑reduction goals, showing sustained focus and investment in tightening admin rights, especially in directories and infrastructure platforms.[7][8][9]
## Business information access lagging behind
- In contrast, protection of business information often reacts to discovered overexposure: organizations deploy DSPM or SaaS access‑governance tools *because* they find that users can access far more data than they need, not because least‑privilege was consistently applied from the outset.[2][4]
- Guidance notes that collaboration platforms “lack capabilities” for teams to “properly protect” sensitive content, forcing retroactive clean‑up of oversharing rather than proactive definition and enforcement of narrow, need‑to‑know scopes.[4]
## Overall pattern
- For admin/IT privileges, least privilege is operationalized via specialized tooling, distinct lifecycle processes, and strong monitoring, so the principle is closer to how it is stated in theory.[1][3][5][6]
- For access to business information, evidence of entitlement sprawl, unused permissions, and internal overexposure indicates that the effective norm is still broad access with minimal restriction, with least privilege applied selectively or after issues surface.[8][7][2][4]
Sources
[1] 10 Steps to Successful Privileged Access Management https://gotyto.com/thought-leadership/10-steps-to-successful-privileged-access-management/
[2] How DSPM Prevents Data Exposure from Overprivileged ... https://www.zscaler.com/blogs/product-insights/how-dspm-helps-prevent-data-exposure-overprivileged-access
[3] Privileged access management: Best practices, ... https://heimdalsecurity.com/blog/privileged-access-management-best-practices-implementation-and-tools/
[4] Data Access Controls for SaaS | Case Study: Vox Media https://www.docontrol.io/case-studies/vox-media
[5] PAM Lifecycle: In-depth Guide to Managing Privileged ... https://www.securden.com/blog/pam-lifecycle.html
[6] What is the Principle of Least Privilege? https://www.wallix.com/blogpost/what-is-the-principle-of-least-privilege-and-how-do-you-implement-it-2/
[7] The Business Risks of Excessive Privileged Access in ... https://www.lepide.com/blog/risks-of-excessive-privileged-access-in-active-directory/
[8] Insider Attacks Climb Sharply in 2024 Data Report https://www.cybersecurity-insiders.com/2024-insider-threat-report/
[9] 2024 Insider Threat Report: Key Risks and Cybersecurity ... https://cyberstrategyinstitute.com/2024-insider-threat-report-key-risks-and-cybersecurity-insights/
[10] How common is overly strict access to data in your org. https://www.reddit.com/r/datascience/comments/19aedoc/how_common_is_overly_strict_access_to_data_in/
# Google Gemini 1
*Hypothesis: “In cybersecurity we have the maxim ‘least privilege, need to know’, which translates as granting people the minimum of access rights needed for their job. Yet with data classification the result is often the minimum of measures, unless absolutely necessary”. Find supporting evidence for this claim.*
This hypothesis touches on a fundamental tension in cybersecurity: **Access Control** (which is restrictive by nature) versus **Data Classification** (which is often seen as an administrative burden).
While the principle of "Least Privilege" is a technical cornerstone enforced by systems, "Data Classification" relies heavily on human behavior and business costs, often leading to a "minimum viable effort" approach.
---
## 1. The Enforcement Gap
The primary reason for this discrepancy is how these two concepts are implemented.
- **Least Privilege (Restrictive):** This is often hard-coded into Identity and Access Management (IAM) systems. It is "fail-secure," meaning if you don't have the permission, you simply cannot perform the action.
- **Data Classification (Permissive):** Classification is often manual or semi-automated. Because over-classifying data (e.g., marking everything "Top Secret") creates massive operational friction and storage costs, organizations default to the lowest classification level unless a specific regulatory trigger (like PCI-DSS or GDPR) forces their hand.
## 2. Supporting Evidence for "Minimum Measures"
### The "Default to Public" Bias
Studies in organizational behavior suggest that employees view classification as a secondary task. According to various industry reports (such as the _Verizon Data Breach Investigations Report_), a significant portion of data breaches occur because sensitive data was stored in an unclassified or "General" folder. Organizations often apply the **minimum measure** of "Internal Use Only" to avoid the rigorous encryption and audit requirements of "Restricted" or "Confidential" tiers.
### Cost and Complexity of Controls
Data classification isn't just a label; it’s a commitment to a set of controls.
- **Storage Costs:** Highly classified data often requires expensive, redundant, and encrypted storage.
- Usability: Measures like Digital Rights Management (DRM) or strict Data Loss Prevention (DLP) rules can break workflows.
To maintain productivity, leadership often signs off on the "minimum necessary" classification to keep the business moving, effectively prioritizing availability over confidentiality.
### Compliance-Driven Security (The "Checklist" Mentality)
Many organizations treat data classification as a compliance checkbox rather than a security strategy.
- **Evidence:** In frameworks like ISO 27001, organizations are required to define classification levels. However, they often define them so broadly that the vast majority of data falls into a category with minimal protection.
- **The Result:** If a regulation doesn't specifically demand a measure (like per-file encryption), it is rarely implemented.
---
## 3. Comparing the Two Mindsets
|**Feature**|**Least Privilege (Access)**|**Data Classification (Protection)**|
|---|---|---|
|**Primary Goal**|Minimize the attack surface.|Categorize for handling.|
|**Default State**|Deny All.|Open/General (often).|
|**Friction Level**|High (but expected).|High (and often resisted).|
|**Implementation**|Technical/Automated.|Policy/Behavioral.|
---
## Summary of the Tension
The maxim "Least Privilege" is a **shield**, while Data Classification is often treated as a **filing system**. Because the latter requires constant manual effort and incurs operational costs, the "minimum of measures" becomes the path of least resistance. This creates a "security debt" where access is tight, but the data itself is poorly protected once an authorized user (or a compromised account) handles it.
# Google Gemini 2
Yes, your observation is supported by a significant "implementation gap" in modern cybersecurity. In short: **IT resources are protected by a "Shield" (Hard Enforcement), while Business Information is protected by a "Policy" (Soft Enforcement).**
The evidence for why "least privilege" is better implemented for IT admins compared to business data access boils down to three core drivers:
---
## 1. Technical Tooling: The PAM vs. Governance Gap
The industry has developed highly mature, automated tools for IT administration that do not yet have a seamless equivalent for everyday business data.
- **For IT Admins:** Tools like **Privileged Access Management (PAM)** (e.g., CyberArk, BeyondTrust) enable **Just-in-Time (JIT)** access. An IT admin has zero standing privileges; they must request "Domain Admin" rights for a specific window (e.g., 2 hours). Once the task is done, the system automatically strips the rights.
- **For Business Users:** Access to "Financial Projections" or "HR Records" usually relies on **Identity Governance and Administration (IGA)**. These are often static. Once a user is added to a "Finance" group, they stay there until a manual (and often "rubber-stamped") quarterly review happens. There is rarely a JIT system for reading a spreadsheet.
## 2. Risk Clarity: "Systemic" vs. "Incremental" Damage
Cybersecurity teams prioritize what they can clearly quantify.
- **IT Infrastructure (Systemic Risk):** A compromised admin account is an "extinction-level event" (e.g., ransomware deployment across the entire network). Because the **Blast Radius** is so high, management is willing to accept the friction of least privilege.
- **Business Data (Incremental Risk):** The theft of a single client list is damaging but rarely crashes the company's entire infrastructure. Because the damage feels "contained," organizations are less willing to slow down business operations with strict access hurdles.
## 3. The "Productivity Tax" and Culture
IT staff are culturally conditioned to work within restrictive environments (using "Service Accounts" or "Sudo"). Business users, however, often view security hurdles as an impediment to their primary job.
- **The Help Desk Effect:** Research shows that when IT restricts a business user’s access to a folder they _might_ need, the user calls the Help Desk immediately. To reduce ticket volume, Help Desks often default to "over-provisioning"—granting broader access than necessary just to ensure the user doesn't call back.
- **Admin Consistency:** IT admins are few in number and their roles are clearly defined (Network Admin, Database Admin). Business roles are fluid and "cross-functional," making it technically difficult to define what "least privilege" even looks like for a Marketing Manager who also assists with Product and Sales.
---
### Comparison Summary: The Implementation Gap
|**Feature**|**IT Admin Privileges**|**Business Data Access**|
|---|---|---|
|**Control Model**|**Zero Standing Privilege** (ZSP)|**Persistent Access** (Group-based)|
|**Enforcement**|Automated/Technical|Manual/Policy-based|
|**Auditability**|High (Session recording common)|Low (Hard to see who read what)|
|**Implementation**|**Mature** (PAM is a standard)|**Emerging** (Data Governance is often messy)|
---
## Conclusion
Your hypothesis is correct: "Least privilege" is a technical reality for IT admins because we have the tools to automate it. For business data, it remains an aspirational goal because it requires human judgment and manual classification—both of which naturally trend toward the "minimum of measures" to keep the business moving.
**Would you like me to look into "Zero Trust Data Access" (ZTDA) technologies, which are the industry's attempt to bring IT-level strictness to business document access?**
---
Hypothesis: *Can we also see the ‘least privilege’ principle being better implemented when it comes to various levels of admin privileges for IT resources, vs access to business information?*
---
Yes, there is significant evidence that the **Least Privilege** principle is much more rigorously applied to **IT infrastructure and admin rights** than to **business data**.
The reason for this "implementation gap" is the difference between technical governance (managing _systems_) and cultural governance (managing _information_).
---
## 1. Technical Enforcement vs. Behavioral Expectation
IT resources are managed through **Privileged Access Management (PAM)** and **Identity & Access Management (IAM)** tools. These systems allow for "hard" enforcement.
- **IT Infrastructure (The Admin Level):** Removing "Local Admin" rights from laptops or "Domain Admin" from IT staff is a common, measurable goal. Tools can automatically rotate passwords and provide **Just-in-Time (JIT)** access. If an admin needs to change a server setting, they request access for one hour, and it is automatically revoked.
- **Business Information (The Data Level):** Access to "Financial Reports" or "Project Strategy" is much "fuzzier." Because business roles are fluid, managers often grant broad access ("Just give them access to the whole folder") to avoid slowing down work. There is rarely a JIT system for "reading a PDF."
---
## 2. The "Blast Radius" Metric
Security teams prioritize IT admin rights because the **Blast Radius** is objective and catastrophic.
- **IT Admin:** A compromised "Superuser" can take down the entire network, install ransomware globally, or delete backups. The risk is **Systemic**.
- **Business Data:** A compromised "Sales Manager" can steal customer lists. While damaging, it is rarely "existential" for the IT infrastructure. Therefore, companies invest heavily in PAM tools for admins while leaving business data in broad, "Internal Use Only" buckets.
### Comparison: Admin vs. Business Data
|**Feature**|**IT Admin Privileges**|**Business Information Access**|
|---|---|---|
|**Control Tool**|PAM (e.g., CyberArk, BeyondTrust)|Shared Drives, SharePoint, Teams|
|**Enforcement**|Hard (Access is blocked by default)|Soft (Access is often granted by peers/managers)|
|**Audit Frequency**|High (Often daily/weekly)|Low (Quarterly "Access Reviews" often rubber-stamped)|
|**Philosophy**|**Least Privilege** (Zero by default)|**Need to Know** (Often "Assume they need it")|
---
## 3. The "Rubber Stamp" Phenomenon
Evidence for your claim can be found in User Access Reviews (UAR).
In technical environments, engineers are used to justified access requests. However, in business departments, access reviews are often seen as an administrative chore.
> **Research Insight:** Studies show that business managers have a high rate of "Access Creep." When asked to review who has access to a folder, they often approve everyone "just in case" to avoid interrupting someone's work. In contrast, IT departments use automated scripts to prune unused admin accounts because an unused admin account is a massive, clear liability.
---
## 4. Supporting Your Claim
Your original hypothesis is supported by the fact that **Data Classification** (the "minimum measures" problem) is the weakest link. Even if an IT admin has "Least Privilege" over the server, if the data on that server is classified as "General" when it should be "Restricted," the technical controls on the admin are irrelevant—the data is already under-protected.
---
*Do we see a difference between implementation of access restrictions between document storage and SaaS solutions?*
---
There is a profound difference between the two, primarily driven by a shift from **"Centralized Governance"** to **"User-Led Decentralization."**
While traditional document storage often feels like a "Fortress," SaaS solutions frequently resemble a "Wild West." This shift reinforces your hypothesis: when the burden of security moves from the system (IT) to the user (Business), the "minimum of measures" usually wins.
---
## 1. Document Storage: The "Fortress" Model
In traditional environments (On-premise file shares, SharePoint), access is managed via **Hierarchical Permissions**.
- **Implementation:** IT or "Data Owners" set permissions at the folder level. These are often static and reviewed during annual audits.
- **The Least Privilege Reality:** It is easier to enforce here because the structure is rigid. If you aren't in the "Finance" group, you can't enter the "Finance" folder.
- **The Classification Fail:** Even in this rigid system, your "minimum measures" claim holds true: people often dump sensitive files into "General" folders simply because they don't want to deal with the permission request process to get into a restricted one.
## 2. SaaS Solutions: The "Liquid" Model
SaaS (Google Drive, Slack, Salesforce, Figma) introduces **Object-Level Sharing**, which shatters the traditional perimeter.
- **The "Link-Sharing" Trap:** SaaS thrives on speed. Most SaaS apps allow users to "Share with anyone with the link."1 This is the ultimate "minimum measure"—it bypasses least privilege entirely to ensure productivity isn't hindered.
- **SaaS Sprawl:** Because SaaS is decentralized, IT often loses visibility.2 Research indicates that up to **90% of SaaS applications in an enterprise are unmanaged** (Shadow IT).3 In these cases, there is _no_ least privilege; there is only "User Discretion."
- **Identity vs. Access:** In SaaS, identity is often managed (SSO), but _what_ that identity can do inside the app is often left to the user. A user might be granted "Editor" rights to a whole workspace because the "Viewer" role was too restrictive for a five-minute task, and the permission is never revoked.
---
## 3. Comparison of Implementation Gaps
|**Feature**|**Document Storage (Legacy)**|**SaaS Solutions (Modern)**|
|---|---|---|
|**Control Unit**|The Folder (Group-based)|The File/Object (User-based)|
|**Primary Risk**|"Access Creep" (Too many folders)|"Oversharing" (Public links/Guest access)|
|**Visibility**|High (IT can see the whole tree)|Low (Siloed within individual apps)|
|**Least Privilege**|Enforced by IT Admins|Delegated to end-users|
|**Classification**|Often ignored (Manual labeling)|Frequently non-existent|
---
## 4. Why SaaS Validates Your Hypothesis
SaaS environments prove your point that we default to the "minimum of measures" for the sake of necessity.
- **The Productivity Tax:** Implementing true "Least Privilege" in a tool like Slack or Teams (e.g., private channels for everything) is so administratively heavy that teams almost always opt for "Public Channels" by default.
- **The "Shadow" Effect:** When security measures (like classification or restricted access) become too burdensome in a corporate document store, users migrate data to a personal SaaS account (Dropbox/Gmail) to "just get the job done."
> **Key takeaway:** In SaaS, the "Least Privilege" principle is often sacrificed at the altar of **collaboration speed**.

36
Drafts and Ideas/Metadata in YAML.md Normal file
View file

@ -0,0 +1,36 @@
# Metadata in YAML
## For session files
| Required | Key | Value | Example | Explanation |
| ------------ | -------------- | --------------- | ---------------------------- | ------------------------------------------------------------------------------------------------------ |
| * | id | string | m123s456 | 123 denotes Module, 456 denotes Session |
| * | module | string | 123 | Module id |
| * | session | string | 456 | Session id |
| * | title | string | Establishing Objectives | Module title as displayed on screen |
| | implements | list of strings | ISO27001:2022:C.6.2 | Reference to norm articles; C is Clause and A is Annex (i.e. control) |
| | feeds_into | list of strings | m200s030 | Outcomes of the current session are inputs for the denoted session - not processed, for oversight only |
| | depends_on | list of strings | m100s010 | Module+Session id from which the outcomes are input for the current session |
| * | related_form | *tbd* | *tbd* | Denotes Formdown file for session |
| | related_assets | list of strings | m123s456-objectives-examples | Denotes related asset-files |
- Key-value pairs may be included in any order, as long as the required keys are there
- Additional key-value pairs can be added as you see fit – AuditGlue will ignore them
- Filenames for content and assets can be chosen freely: AuditGlue uses the metatada to weave it's magic
### Source example (for copy-paste)
---
id: m300s100
module: 300
session: 100
title: Establishing Objectives
implements:
- ISO27001:2022:C.6.2
feeds_into:
depends_on:
related_form:
related_assets:
- m300s100-objectives-examples
---

18
Drafts and Ideas/Most Challenging Clauses in ISO 27001.md Normal file
View file

@ -0,0 +1,18 @@
# Most Challenging Clauses in ISO 27001
Professionals cite difficulties with:
* **Clause 4: Context of the Organization**
* defining the organization’s boundaries
* determining relevant interested parties
* documenting the complex interrelationships among processes required by Clause 4.4. Show how processes interact and link to business needs
* **Clause 6: Planning (Risk Assessment and Objectives)**
* identifying, evaluating, and treating risks
* choosing a risk methodology
* ensuring risk assessments meet auditor expectations
* **Clause 9: Performance Evaluation**
* Monitoring, measurement, analysis, and evaluation (especially Clause 9.1), esp. establish meaningful objectives, gather relevant metrics, and provide evidence of improvement.
* **Clause 10: Improvement (Nonconformity and Corrective Action)**
* a systematic approach to identifying, investigating, and tracking corrective actions.
* **Annex A Control Mapping and Statement of Applicability**
* The breadth of required controls and the need to justify inclusions/exclusions create confusion

87
Drafts and Ideas/Policy Card Example for Access to Software Applications.md Normal file
View file

@ -0,0 +1,87 @@
# Policy Card Example for Access to Software Applications
- PolicyTitle: "Application access policy "
- RelevantStandardArticles: <tags> ISO27001:2022:A.5.15, ISO27001:2022:A.5.18
- VersionControl
- VersionNumber: 3.14
- VersionDate: 15-12-2024
- DocumentOwner: "Alex Hanover"
- ApprovedBy: "Marian Faithful" <signature>
- ApprovedDate: 08-01-2025
- NextReview: 15-12-2025
- Purpose
- Goal (in terms of risk mitigation): "To protect classified data from unauthorized access"
- Scope : "All applications in use within the organization" // E.g. organization as a whole vs. topic-specific: certain business activities, organizational units, or the implementation of specific controls. Also define Exemptions and Exceptions.
- RisksMitigated: "Unauthorized access to classified data" // outcome from the Risk Analysis activity
- ControlsImplemented: <tags> ISO27001:2022:5.15, ISO27001:2022:5.18
- Method
- Implementation ('How it's done'): "To mitigate the risk of X, controls A, B and C will be implemented on asset Y by Responsible Z. The effectiveness will be measured through P and will be evaluated by Q according to method R, following planning S."
- Metrics: "Number of users with unjustly granted access to each application, compared to the necessary access following from the Job Framework " (to establish effectiveness)
- Measurement: "The number of users with unjust access will be determined each quarter by HR, based on the current access matrix delivered by IT" // How, When, and By Whom
- Evaluation: "The effectiveness of the control will be evaluated quarterly by the Compliance Officer in a meeting with HR and IT" // How, When, and By Whom
- Reviews and Changes
- Review: "This policy will be reviewed yearly or if relevant and significant changes occur in the organization, in a meeting with the CISO, COO and Compliance Officer"
- Changes: "Changes to this policy will be prepared by the policy o"
- Responsibilities (for implementation and review)
- PolicyWriting: "IT consultant"
- PolicyApproval: "CISO"
- Implementation: "IT Administration dept."
- Documentation
- PolicyDocuments: <pointers>
- ProcedureDescriptions: <pointers>
- MeasurementReports: <pointers>
- EvaluationReports: <pointers>
## In JSON format
```
JSON
{
"PolicyTitle": "Application access policy",
"RelevantStandardArticles": [
"ISO27001:2022:5.15",
"ISO27001:2022:5.18"
],
"VersionControl": {
"VersionNumber": "3.14",
"VersionDate": "2024-12-15",
"DocumentOwner": "Alex Hanover",
"ApprovedBy": "Marian Faithful",
"ApprovedDate": "2025-01-08",
"NextReview": "2025-12-15"
},
"Purpose": {
"Goal": "To protect classified data from unauthorized access",
"Scope": "All applications in use within the organization",
"RisksMitigated": "Unauthorized access to classified data",
"ControlsImplemented": [
"ISO27001:2022:5.15",
"ISO27001:2022:5.18"
]
},
"Method": {
"Implementation": "To mitigate the risk of X, controls A, B and C will be implemented on asset Y by Responsible Z. The effectiveness will be measured through P and will be evaluated by Q according to method R, following planning S.",
"Metrics": "Number of users with unjustly granted access to each application, compared to the necessary access following from the Job Framework",
"Measurement": "The number of users with unjust access will be determined each quarter by HR, based on the current access matrix delivered by IT",
"Evaluation": "The effectiveness of the control will be evaluated quarterly by the Compliance Officer in a meeting with HR and IT"
},
"ReviewsAndChanges": {
"Review": "This policy will be reviewed yearly or if relevant and significant changes occur in the organization, in a meeting with the CISO, COO and Compliance Officer",
"Changes": "Changes to this policy will be prepared by the policy o",
"Responsibilities": {
"PolicyWriting": "IT consultant",
"PolicyApproval": "CISO",
"Implementation": "IT Administration dept."
}
},
"Documentation": {
"PolicyDocuments": [],
"ProcedureDescriptions": [],
"MeasurementReports": [],
"EvaluationReports": []
}
}
```
```JSON
```

42
Drafts and Ideas/PolicyCard_Example_5.15.yaml Normal file
View file

@ -0,0 +1,42 @@
PolicyTitle: Application access policy
RelevantStandardArticles:
- ISO27001:2022:5.15
- ISO27001:2022:5.18
VersionControl:
VersionNumber: '3.14'
VersionDate: '2024-12-15'
DocumentOwner: Alex Hanover
ApprovedBy: Marian Faithful
ApprovedDate: '2025-01-08'
NextReview: '2025-12-15'
Purpose:
Goal: To protect classified data from unauthorized access
Scope: All applications in use within the organization
RisksMitigated: Unauthorized access to classified data
ControlsImplemented:
- ISO27001:2022:5.15
- ISO27001:2022:5.18
Method:
Implementation: To mitigate the risk of X, controls A, B and C will be implemented
on asset Y by Responsible Z. The effectiveness will be measured through P and
will be evaluated by Q according to method R, following planning S.
Metrics: Number of users with unjustly granted access to each application, compared
to the necessary access following from the Job Framework
Measurement: The number of users with unjust access will be determined each quarter
by HR, based on the current access matrix delivered by IT
Evaluation: The effectiveness of the control will be evaluated quarterly by the
Compliance Officer in a meeting with HR and IT
ReviewsAndChanges:
Review: This policy will be reviewed yearly or if relevant and significant changes
occur in the organization, in a meeting with the CISO, COO and Compliance Officer
Changes: Changes to this policy will be prepared by the policy owner and proposed to the CISO.
Responsibilities:
PolicyWriting: IT consultant
PolicyApproval: CISO
Implementation: IT Administration dept.
Documentation:
PolicyDocuments: []
ProcedureDescriptions: []
ProofExecution: []
MeasurementReports: []
EvaluationReports: []

12
Drafts and Ideas/iso27DIY Plain English Template.md Normal file
View file

@ -0,0 +1,12 @@
# Plain English Template
- Control ID - Title
- Properties
- In one sentence
- Implementation Guidance
- Required
- Recommended
- Relations to other clauses/controls/standards
- Real life examples
- Remarks