Organized folders, edited metadata note
This commit is contained in:
parent
df038765c0
commit
e806e6764b
56 changed files with 113 additions and 55 deletions
|
|
@ -0,0 +1,6 @@
|
|||
# Data classification: how to make labels stick?
|
||||
|
||||
Data travels; how to make labels stick?
|
||||
|
||||
Links to the [Privacy in ISO 27001](../../../Corpus/Standards/ISO27x/Privacy%20in%20ISO%2027001.md) issue of [Data Provenance](../../../Corpus/Standards/AVG/Data%20Provenance.md) .
|
||||
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
# Example of ISO 27001 mystique
|
||||
|
||||
ISO 27001 is a framework, and you cannot successfully implement it by treating the text of the standard as a series of instructions to be followed in the order in which they were printed. If you try that, things will become very confusing very quickly.
|
||||
|
||||
For example, the requirement of having an information security policy is first (?) mentioned in [Chapter 5.1](../../Corpus/MoCs/ISO_27001_2022_5.1_MoC%20Leadership%20and%20commitment.md), "Leadership and commitment", where it says that top management must have it established, *together* with information security objectives. Then in [Chapter 5.2](../../../Corpus/Standards/ISO27x/OST/27001/EN/c-5.2-Policy.md), 'Policy', it states that these objectives form *part of* the information security policy, referencing forward to [Chapter 6.2](../../Corpus/MoCs/ISO_27001_2022_6.2_MoC%20Information%20security%20objectives%20and%20planning%20to%20achieve%20them.md), "Information security objectives and planning to achieve them", which demands that organizations should set objectives consistent with the policy. Of course there's also a corresponding Control called "Policies for information security" ([5.1](../../../Corpus/Standards/ISO27x/legacy/iso27DIY%20mk%20I/ISO_27002_2022_5.1_MoC%20Policies%20for%20information%20security.md)), which explains that there will be an information security policy at the highest level of the organization, including objectives "or the framework for setting objectives", and further "topic-specific policies as needed", which of course need their own objectives.
|
||||
|
||||
Programmers may love this kind of recursiveness when it's in coding exercises.
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
This note relates to the [ISO27DIY Business model](../../../Corpus/Standards/ISO27x/legacy/iso27DIY%20mk%20I/ISO27DIY%20Business%20model.md)
|
||||
|
||||
Probleem: de GRC software wordt aangekocht om een operationeel probleem van de compliance officer op te lossen.
|
||||
|
||||
De software komt meestal pas later (en wordt pas gevuld als de kennis van wat ISO is en van het proces er al is, als het jargon al is ingesleten)
|
||||
|
||||
Eerst komt de consultant uitleggen hoe ISO werkt en wordt hulp geboden bij Wat je Waar moet documenteren, en Hoe (denk aan de risico-identificatie en de stakeholder-analyse: wat is een in-scope risico, hoe verwoordt je het precies. Wat is een stakeholder, wat is zijn in-scope belang, etc.).
|
||||
Dan ontstaat de documentatie, meestal in Excel en Word documenten.
|
||||
Dan de realisering dat het onhandig is en niet schaalt.
|
||||
Dan wordt software geselecteerd en geïmplementeerd.
|
||||
Pas dan wordt de software daadwerkelijk gebruikt, en meestal door een deskundige staffunctionaris.
|
||||
|
||||
Inmiddels staat het dan zover af van de dagelijkse praktijk op de werkvloer, dat de heilige graal van security by design en in de haarvaten van de organisatie, niet gehaald kan worden.
|
||||
Voor iedere (interne) audit is extra effort nodig om te graven in de operationele documentatie om de audit documentatie naar boven te krijgen.
|
||||
|
||||
Wat nu als je de documentatie kun genereren op het moment dat relevante feiten (identificatie en weging van risico’s, keuze van maatregelen, bewaken van de implementatie, monitoren van de resultaten en bijsturen) plaatsvinden? Door ze voorafgaand aan een SCRUM, Team- of afdelingsoverleg of ontwerpmeeting te agenderen, en ze in de notulen te ‘marken’? Door operationele reports en logs te koppelen naar de ISO-administratie?
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
# Hoe dwing je verantwoordelijkheid af?
|
||||
|
||||
Een universiteit biedt onderzoeksafdelingen de mogelijkheid om vrijelijk hun applicaties en databases op te tuigen binnen hun eigen Kubernetes containers. Daarbij zijn ze zelf verantwoordelijk voor de informatiebeveiliging daarvan.
|
||||
|
||||
Het is vervolgens aan de IT afdeling om de containers te ‘deployen’. Daarbij ontdekken ze dat veel containers / applicaties / databases onveilig geconfigureerd zijn, oude versies van software met bekende kwetsbaarheden herbergen, etc.
|
||||
|
||||
Mijn stelling is dat er voor het succesvolle delegeren van de verantwoordelijk voor informatiebeveiliging in ieder geval nodig is: een prikkel om het ook goed te doen (bijv. niet in beheer nemen, kosten in rekening brengen, kwaliteit van de beveiliging als KPI van de afdeling), en kennis en resources het uit te voeren (of financiele middelen om het te laten doen).
|
||||
|
||||
Is er literatuur beschikbaar over deze kwestie? Zijn er andere succesvoorwaarden bekend?
|
||||
|
||||
|
|
@ -0,0 +1,290 @@
|
|||
# Least privilege, need-to-know: principles vs practice
|
||||
|
||||
*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**.
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
# Perverse prikkels in de normindustrie
|
||||
|
||||
- Nodeloos complex geformuleerde norm, vereist consultants om hem begrijpbaar te maken
|
||||
- Consultants zijn er niet bij gebaat om de eenvoud te laten zien (want minder uren)
|
||||
- Bestaande software vereist diepgaande domeinkennis om het te implementeren en te bedienen. Wordt veelal verkocht via ‘partner kanalen’ (ISO 27001 consultants).
|
||||
- Certificerende Instanties doen het voorkomen dat ze objectief toetsen t.o.v. Een norm die maar op één manier kan worden uitgelegd, maar in de praktijk wil geen CI bekend staan als de strengste partij met het laagste slagingspercentage.
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
# Privacy protection in Databases
|
||||
|
||||
[A deep dive into privacy-protecting databases by VentureBeat](https://venturebeat.com/business/a-deep-dive-into-privacy-protecting-databases/amp/)
|
||||
|
||||
[Differential privacy](https://en.wikipedia.org/wiki/Differential_privacy?wprov=sfti1)
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
- Zorgen dat het managen van Infosec risico’s een natuurlijk onderdeel wordt van alle activiteiten rond informatieverwerking.
|
||||
- Bedrijven laten zien dat ze dit zelf kunnen. Ze doen het al voor een groot deel maar hebben nooit geleerd de administratie goed te voeren
|
||||
- Een stuk software bieden waarmee ze de administratie zelf kunnen opzetten en gaandeweg leren hun informatierisico’s norm-conform te beheersen.
|
||||
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
# Voordelen van processvolwassenheid
|
||||
|
||||
Het CMM (Capability Maturity Model) streeft naar hogere procesvolwassenheid omdat volwassener processen een aantal concrete voordelen opleveren:
|
||||
|
||||
**Voorspelbaarheid** — je weet wat een proces oplevert, hoe lang het duurt en wat het kost. Verrassingen nemen af naarmate processen herhaalbaarder worden.
|
||||
|
||||
**Beheersbaarheid** — je kunt bijsturen omdat je meet en begrijpt wat er gebeurt. Bij lage volwassenheid stuur je op gevoel of incident.
|
||||
|
||||
**Kwaliteitsborging** — hogere volwassenheid betekent dat kwaliteit ingebakken zit in het proces, niet afhankelijk is van de individuele medewerker die het uitvoert.
|
||||
|
||||
**Schaalbaarheid** — gedocumenteerde en herhaalbare processen zijn overdraagbaar en schaalbaar, onafhankelijk van sleutelpersonen.
|
||||
|
||||
**Continu verbeteren wordt mogelijk** — je kunt pas structureel verbeteren als je een baseline hebt. Zonder gedefinieerde processen verbeter je ad hoc, niet systematisch.
|
||||
|
||||
**Auditbaarheid** — je kunt aantonen wat je doet en hebt gedaan, wat essentieel is voor certificering, compliance en vertrouwen bij klanten of toezichthouders.
|
||||
|
||||
De ironie is dat dit vrijwel exact de drie peilers zijn die jij voor ISO 27001 beschrijft — risicomanagement (beheersbaarheid), continue verbetering, en borging (aantoonbaarheid). CMM en ISO 27001 adresseren in essentie hetzelfde probleem, alleen vanuit een andere invalshoek.
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
# Weerbaarheid: bereid je voor op verstoring
|
||||
|
||||
*Engels: Planning for Disruption*
|
||||
|
||||
De digitale weerbaarheid van een organisatie is een belangrijke factor in de bedrijfszekerheid. Die weerbaarheid bereik je enerzijds door je te beschermen tegen dreigingen, en anderzijds door de capaciteiten te bouwen waarmee je adequaat kunt reageren op incidenten en kunt herstellen van een aanval of storing. Goed beleid voor digitale weerbaarheid is een verplichting vanuit onder andere de NIS 2 en de ISO 27001 / NEN 7510.
|
||||
|
||||
Dit document richt zich op het plannen voor, en het herstellen van, incidenten en verstoringen. Het beschrijft de vier bouwstenen om het opbouwen van weerbaarheid planmatig aan te pakken. Dit zijn:
|
||||
|
||||
- Business Impact Analyse
|
||||
- Bedrijfscontinuïteitsplan
|
||||
- Incident Response Plan (IRP)
|
||||
- Herstelplan
|
||||
|
||||
Met de **Business Impact Analyse** (BIA) worden de kritische bedrijfsprocessen en hun kwetsbaarheid voor verstoringen in kaart gebracht. Hiermee wordt het belang van de verschillende systemen verduidelijkt voor de bedrijfsvoering, en kan de vertaalslag gemaakt worden naar prioriteiten voor het treffen van preventieve maatregelen (zoals noodvoorzieningen en alternatieve werkwijzen) en het uitvoeren van herstelwerkzaamheden. De BIA helpt ook om technische afdelingen en leveranciers hiervoor kaders te geven.
|
||||
De BIA is daarmee een ijkpunt voor de andere componenten (het BCP, het IRP en het HP).
|
||||
|
||||
Het **Bedrijfscontinuïteitsplan** (BCP) richt zich op de continuïteit van essentiële processen tijdens verstoringen. Het beschrijft hoe de bedrijfsvoering doorgang kan vinden door de inzet van mensen, middelen en techniek, inclusief de toeleveringsketen. Een BCP beschrijft bijvoorbeeld de inzet van alternatieve locaties, tijdelijk personeel, noodapparatuur en alternatieve werkwijzen.
|
||||
|
||||
Het **Incident Response Plan** (IRP) adresseert de directe reacties op veiligheidsincidenten en dreigingen. Het bevat een stappenplan voor het detecteren, analyseren, beheersen en elimineren van gevaren en verstoringen
|
||||
|
||||
De focus van het **Herstelplan** (HP) is op werkzaamheden die de normale gang van zaken weer moeten herstellen. Het gaat dan om IT systemen en technische infrastructuur (servers, databases, netwerken en software), maar ook om het weer in gang zetten van de normale bedrijfsprocessen met de normale voorzieningen.
|
||||
|
||||
De verschillende plannen hoeven niet noodzakelijkerwijs als separate documenten met deze titels te bestaan – zo worden de verschillende onderdelen vaak gecombineerd in een 'Uitwijk- en herstelplan' of een 'Calamiteitenplan'
|
||||
|
||||
---
|
||||
**Engelse termen**
|
||||
Business Impact Analyse (BIA)
|
||||
Business Continuity Plan (BCP)
|
||||
Incident Response Plan (IRP)
|
||||
Disaster Recovery Plan (DRP)
|
||||
|
||||
|
||||
**Metrics**
|
||||
Kwantificeren hoe lang systemen uit de lucht mogen zijn, voordat de impact op de bedrijfsvoering onacceptabel wordt.
|
||||
- Maximum tolerable period of disruption (MTPD) – of business process
|
||||
- Maximum Downtime (MTD) – of assets
|
||||
- Recovery Time Objectives (RTO) – of processes; time for back to normal
|
||||
- Recovery Point Objectives (RPO) – of assets; acceptable data loss; the point in time that you wish to recover to
|
||||
|
||||
|
||||
The BIA provides the business context and impact metrics that guide the creation of the BCP, IRP and DRP. It answers fundamental questions like "What happens to revenue if this system is down for 4 hours?" or "Which departments cannot function without this application?" This quantitative foundation ensures that technical recovery efforts align with business needs and that resources are allocated based on actual business impact rather than assumptions.
|
||||
The BIA serves as a bridge between business stakeholders and technical teams, translating business requirements into actionable technical specifications across all three planning domains.
|
||||
497
marketing/publications/Scratch file/longlist.md
Normal file
497
marketing/publications/Scratch file/longlist.md
Normal file
|
|
@ -0,0 +1,497 @@
|
|||
# Scratch file long list
|
||||
|
||||
---
|
||||
|
||||
**Wie IT ziet als een puinruimer, calculeert de schade al in.**
|
||||
|
||||
---
|
||||
**Pantone colors**
|
||||
|
||||
These are the Pantone colors we chose for our Canvases.
|
||||
|
||||
Pink is for... yellow is for ... etc. You may notice they resemble the colors of 3M's Post-It notes.
|
||||
|
||||
This is no coincidence. We like the playfulness and open-world possibilities they can bring to business environments.
|
||||
|
||||
Just as our canvases do. They also introduce a certain playfulness - the possibility for discovery and exchange of ideas, in the stern world of risk management and compliance.
|
||||
|
||||
Inviting people to be creative with and develop ownership for the risks that come with being inventive.
|
||||
|
||||
+ Call to action
|
||||
---
|
||||
**Stukje: informatieveiligheid in projecten**
|
||||
|
||||
Denkend aan Control 5.8 - Information security in project management:
|
||||
|
||||
"To ensure information security risks related to projects and deliverables are effectively addressed in project management throughout the project life cycle".
|
||||
|
||||
https://www.ipma.nl/iso-voor-projectmanagement
|
||||
---
|
||||
**Keeping projects secure**
|
||||
|
||||
Risico's op 3 vlakken:
|
||||
- Het op te leveren product (vanaf ontwerp via testen tot oplevering)
|
||||
- De uitvoering van het project (incl de mensen en tooling)
|
||||
- De overdracht aan en borging in de staande organisatie
|
||||
|
||||
Mind map van de risico's / kwetsbaarheden
|
||||
|
||||
Check ISO 27001 en NIST
|
||||
|
||||
---
|
||||
|
||||
**NIST CSF 2.0 GV.RR-01**
|
||||
|
||||
---
|
||||
|
||||
Organizational leadership takes responsibility for decisions associated with cybersecurity risks and establishes a culture that is risk-aware, behaves in an ethical manner, and promotes continuous improvement
|
||||
|
||||
---
|
||||
**Gretzky:** I don't skate to where the risks are, I skate to where they gonna be
|
||||
|
||||
---
|
||||
|
||||
Accepting posts!
|
||||
|
||||
---
|
||||
|
||||
**Top Security Awareness startups you should follow**
|
||||
|
||||
https://voiceofciso.com/top-security-awareness-startups-you-should-follow/
|
||||
---
|
||||
**Takeaways of 2023 Data Breach Investigations Report (DBIR)**
|
||||
|
||||
https://www.verizon.com/business/resources/T547/reports/2023-data-breach-investigations-report-dbir.pdf?utm_source=danielmiessler.com&utm_medium=newsletter&utm_campaign=unsupervised-learning-newsletter-no-386
|
||||
|
||||
Takeaways:
|
||||
1. Social engineering attacks are up, with Business Email Compromise and ransomware leading the charge.
|
||||
2. Most breaches involve human error and external actors, and the primary motives are still financial.
|
||||
3. Business Email Compromise (BEC) attacks have almost doubled and represent more than 50% of incidents in the Social Engineering pattern.
|
||||
4. 74% of all breaches involve human error; 83% involve external actors.
|
||||
5. Financial motives underlie 95% of breaches.
|
||||
|
||||
---
|
||||
Miessler newsletter
|
||||
|
||||
---
|
||||
|
||||
|
||||
**New SEC cyber rules will force ISMS**
|
||||
|
||||
New SEC cyber rules will force businesses to think beyond IT security | Security Info Watch
|
||||
|
||||
https://www.securityinfowatch.com/cybersecurity/article/53061276/new-sec-cyber-rules-will-force-businesses-to-think-beyond-it-security
|
||||
---
|
||||
**MEME:** If you could just.... Stop presenting your services catalog as a fit-gap analysis. That would be nice. I'm looking at you, MSP's!
|
||||
|
||||
---
|
||||
|
||||
**The problem with awareness campaigns**
|
||||
|
||||
They only deal with known risks
|
||||
People are likely already aware
|
||||
- They teach a reflex (don't click, pause for 5 secs)
|
||||
- They train on answering the question
|
||||
---
|
||||
**Informatiebeveiliging blijft beperkt zolang we het een IT probleem maken**
|
||||
|
||||
Want:
|
||||
Beperkt mandaat
|
||||
Beperkte toolkit/comfort zone
|
||||
Business pakt geen verantwoordelijkheid
|
||||
|
||||
Hoe dan wel?
|
||||
1. Reken de business ook af op hun efforts rond informatieveiligheid (wel met duidelijke scoping van hun verantwoordelijkheden, instrumentarium en heldere rapportageverpichtingen)
|
||||
2. Laat informatiebeveiliging bij IT, maar breng informatieveiligheid in de lijn (kijk welke onderdelen wel bij IT horen en welke daarvan dienend zijn aan de lijn, zoals monitoring en logging) - denkexperiment: named admin accounts: wie is waar verantwoordelijk voor en hoe bewaak je dat?
|
||||
---
|
||||
As long as security is not part of business OKR, it won't happen
|
||||
|
||||
---
|
||||
|
||||
Increase cyber resilience by empowering employees
|
||||
|
||||
---
|
||||
|
||||
**Solve your shadow IT Problem**
|
||||
|
||||
By acknowledging user agency (paradoxically)
|
||||
|
||||
---
|
||||
|
||||
**MEME:** I pity the fool who thinks shadow it can be
|
||||
|
||||
---
|
||||
|
||||
**Morgan Stanley betaalt 6,5 miljoen dollar wegens datalek door afgedankte servers - Security.NL**
|
||||
|
||||
https://www.security.nl/posting/818992/Morgan+Stanley+betaalt+6%2C5+miljoen+dollar+wegens+datalek+door+afgedankt?channel=rss
|
||||
---
|
||||
**Cybersecurity Is a Social, Policy, and Wicked Problem**
|
||||
|
||||
https://taosecurity.blogspot.com/2023/06/cybersecurity-is-social-policy-and.html
|
||||
---
|
||||
**Guarding Against the Insider Threat: Do Your Employees Pose the Greatest Risk? - Cyber Defense Magazine**
|
||||
|
||||
https://www.cyberdefensemagazine.com/guarding-against-the-insider-threat-do-your-employees-pose-the-greatest-risk/
|
||||
---
|
||||
**Employees breaking security policies just dangerous as being hacked, Kaspersky global study shows**
|
||||
|
||||
https://www.itsecurityguru.org/2023/11/22/employees-breaking-security-policies-just-dangerous-as-being-hacked-kaspersky-global-study-shows/?utm_source=rss&utm_medium=rss&utm_campaign=employees-breaking-security-policies-just-dangerous-as-being-hacked-kaspersky-global-study-shows
|
||||
---
|
||||
**Small Business Cybersecurity Hampered by Fear of Change, Judgement - Security Boulevard**
|
||||
|
||||
https://securityboulevard.com/2023/11/small-business-cybersecurity-hampered-by-fear-of-change-judgement/
|
||||
---
|
||||
**The drawbacks of using video training for your security awareness program - Security Boulevard**
|
||||
|
||||
https://securityboulevard.com/2023/11/the-drawbacks-of-using-video-training-for-your-security-awareness-program/
|
||||
---
|
||||
**How to deal with the risks of shadow it**
|
||||
|
||||
We'll have shadow it as long as we'll have Excel. Or any other tooling that work teams can use of which the control of functionality is not strictly centralized.
|
||||
|
||||
And that is essential to business otherwise we would lose all agility and opportunity for creativity.
|
||||
|
||||
Change + Agility = Shadow IT
|
||||
|
||||
Changes necessitates shadow IT
|
||||
|
||||
Shadow IT is here to stay and that's a good thing. But we have to deal with risks.
|
||||
|
||||
---
|
||||
**Als een kind (filmpje)**
|
||||
|
||||
Dit is Inge
|
||||
Inge kijkt een filmpje over IB
|
||||
Want dat moet
|
||||
Inge baalt er van, omdat ze wordt aangesproken alsof ze een kind is
|
||||
Ondertussen klikt ze wat mails weg
|
||||
Aan het eind van het filmpje krijgt ze een meerkeuzevraag.
|
||||
|
||||
Dit moet iedere week. Van de Security Officer. Die denkt dat ze hierdoor veiliger gaat werken.
|
||||
|
||||
---
|
||||
|
||||
|
||||
**SIGRA Opleidingen Privacy & Informatieveiligheid | sigra**
|
||||
|
||||
https://www.sigra.nl/expertisecentrum-privacy-informatieveiligheid/opleidingen-privacy-informatieveiligheid
|
||||
---
|
||||
**People make the best exploits**
|
||||
|
||||
Quote from Mr Robot season 1
|
||||
Link to Kevin Mitnick social engineering
|
||||
|
||||
---
|
||||
|
||||
**Content: voorbereiden op een NEN 7510 implementatie**
|
||||
|
||||
---
|
||||
|
||||
**CMM: hoe kom je van volwassenheidsniveau 0 naar 5?**
|
||||
|
||||
---
|
||||
|
||||
Wil je ook een IBB dat
|
||||
|
||||
---
|
||||
|
||||
**Integriteit wordt vaak vergeten**
|
||||
|
||||
Of alleen geïnterpreteerd als: door technische issues of outsider threats gecompromitteerd
|
||||
Terwijl het vaak in het proces kan ontstaan, zie bijv zaaksysteem Zeeland of urenverantwoording Junis
|
||||
|
||||
---
|
||||
|
||||
**How do you involve your project team in managing risks?**
|
||||
|
||||
---
|
||||
|
||||
**Content: risico's in nieuwe projecten**
|
||||
|
||||
Hoort dit thuis onder IT, Kwaliteit of in de lijn?
|
||||
De uitvoering van het risicomanagement moet een lijnverantwoordelijkheid zijn en in de managementcyclus geborgd worden.
|
||||
De verantwoordelijkheid voor het instrument ligt wel bij de Kwaliteitsafdeling.
|
||||
|
||||
Moet je niet eerst al je processen beschrijven, vóór je dit gaat doen?
|
||||
Nee, het is complementair. Procesbeschrijvingen leggen achteraf vast wat bekend is, en hoe de dingen zouden moeten gaan.
|
||||
Vanuit een KS-bril zou je het liefst willen dat er bij een verandering in het werk, in systemen, of in de omgeving, eerst een analyse wordt uitgevoerd hoe het proces moet worden aangepast en wat daarbij de risico's zijn, en dat pas daarna het werk verandert.
|
||||
De realiteit is dat het werk wordt aangepast, en pas in de volgende KS cyclus gekeken wordt hoe we de procesbeschrijving moeten aanpassen.
|
||||
|
||||
---
|
||||
|
||||
**Eigenaarschap in de business**
|
||||
|
||||
Verantwoordelijkheid en eigenaarschap in de business bereik je alleen, als het managen van risico's voor informatieveiligheid in de werkprocessen, onderdeel wordt van het algemene management proces.
|
||||
Dat bereik je door managers verantwoordelijk te maken voor de performance op dat vlak, net zoals ze aangesproken worden op winst en verlies, personeelsmanagement en kwaliteit.
|
||||
|
||||
---
|
||||
|
||||
**Boek: houding in Workshop**
|
||||
|
||||
Ja leuk dat we dit doen, maar als wij het prioriteit vinden zegt een CISO, manager of directeur iets anders
|
||||
1) is dus de attitude die door de methode veranderd wordt
|
||||
2) overtuigen van de ander in AO, maar ook door onderbouwing met risico analyse
|
||||
---
|
||||
**Querying for hidden risks**
|
||||
|
||||
Earlier LinkedIn post on that subject
|
||||
Plus Google questionnaire with McGyver
|
||||
|
||||
---
|
||||
|
||||
**faalkosten in de bouw - Corporatie branche**
|
||||
|
||||
https://www.google.com/search?q=faalkosten+in+de+bouw&ie=UTF-8&oe=UTF-8&hl=en-nl&client=safari
|
||||
---
|
||||
**ESG (Environmental, Social, and Governance)**
|
||||
|
||||
Employee participation is crucial to the success of ESG directives for several reasons (the canvas method can be a way to):
|
||||
|
||||
1. **Enhanced Implementation and Compliance**:
|
||||
- Ownership and Accountability: When employees are actively involved, they are more likely to take ownership of ESG initiatives, ensuring better implementation and compliance.
|
||||
- Ground-Level Insights: Employees often have valuable insights into operational aspects and can identify practical solutions to meet ESG goals effectively.
|
||||
|
||||
2. **Improved Sustainability Practices**:
|
||||
- Environmental Initiatives: Employees can contribute to reducing waste, improving energy efficiency, and adopting sustainable practices in their daily operations.
|
||||
- Social Contributions: Active participation in community engagement, volunteer programs, and diversity and inclusion efforts strengthens the social impact of the company.
|
||||
|
||||
3. **Enhanced Governance**:
|
||||
- Ethical Behavior: Employee participation in governance practices, such as ethical training and whistleblowing mechanisms, helps uphold high standards of integrity and transparency.
|
||||
- Feedback and Communication: Open channels for feedback enable employees to report on governance issues and suggest improvements, fostering a culture of continuous improvement.
|
||||
|
||||
4. **Increased Engagement and Morale**:
|
||||
- Purpose and Motivation: When employees are part of ESG initiatives, they feel a sense of purpose and are more motivated, leading to higher job satisfaction and retention.
|
||||
- Skill Development: Participation in ESG projects can provide employees with opportunities for skill development and career growth, further enhancing their engagement.
|
||||
|
||||
5. **Innovation and Competitive Advantage**:
|
||||
- Creative Solutions: Engaged employees are more likely to propose innovative solutions for ESG challenges, giving the company a competitive edge.
|
||||
- Brand Reputation: Companies with active employee participation in ESG are perceived more positively by customers, investors, and other stakeholders, enhancing their reputation and market position.
|
||||
|
||||
6. **Regulatory and Reporting Compliance**:
|
||||
- Accurate Reporting: Employees who are aware and involved in ESG practices are better equipped to provide accurate data and insights for ESG reporting, ensuring compliance with regulatory requirements.
|
||||
- Proactive Adaptation: Active participation helps the company stay ahead of regulatory changes and adapt proactively to new ESG-related laws and standards.
|
||||
|
||||
7. **Stakeholder Engagement**:
|
||||
- Community Relations: Employees can act as ambassadors of the company's ESG initiatives in the community, strengthening relationships with external stakeholders.
|
||||
- Investor Confidence: Demonstrating robust employee participation in ESG efforts can build confidence in the company's long-term sustainability and governance practices.
|
||||
|
||||
In summary, employee participation is vital for the successful execution and sustainability of ESG directives. It drives better implementation, fosters a culture of ethical behavior, enhances employee morale and engagement and contributes to the overall competitive advantage and reputation of the organization.
|
||||
|
||||
---
|
||||
**Phishing awareness campaigns**
|
||||
|
||||
Wrongly named, because it's about being aware of one's own gullibility and/or onzorgvuldigheid
|
||||
|
||||
---
|
||||
**Is that web tool safe?**
|
||||
|
||||
Just found this great tool through SANS Security Awareness Community
|
||||
https://web.universiteitleiden.nl/assets/toolpicker/?lang=en
|
||||
---
|
||||
**Waarom werkt de implementatie van uw GRC Tooling zo slecht?**
|
||||
|
||||
gebrek aan volwassenheid
|
||||
geen business risico's
|
||||
"2 reasons why your GRC Tool implementation is failing"
|
||||
|
||||
SANS forum: maturity for SMEs
|
||||
|
||||
---
|
||||
Announce FortMesa partnership
|
||||
|
||||
---
|
||||
**Blogpost: Guidance for high-risk individuals on protecting your accounts and devices**
|
||||
|
||||
https://www.ncsc.gov.uk/collection/defending-democracy/guidance-for-high-risk-individuals
|
||||
---
|
||||
**RAM-systeem van de Belastingdienst**
|
||||
|
||||
https://www.nrc.nl/nieuws/2025/03/12/van-prostituees-tot-belgische-pensionados-in-het-privacyschendende-ram-systeem-van-de-belastingdienst-heerste-de-willekeur-a4886148
|
||||
---
|
||||
Mapgood en andere risico inventarisaties vergelijken met de CM voor blogpost
|
||||
|
||||
Er wordt veel gezocht op MAPGOOD
|
||||
|
||||
---
|
||||
hockey protective gear laid out on the floor - Google Search
|
||||
|
||||
https://www.google.com/search?client=safari&sca_esv=d777291650d83160&hl=en-nl&channel=30&udm=2&fbs=ABzOT_CWdhQLP1FcmU5B0fn3xuWpA-dk4wpBWOGsoR7DG5zJBtmuEdhfywyzhendkLDnhcrGv0bvsF02PE9wAganQ-f1_Kd4P04qA1S-9-QK1sT3LFPxW3X361XTv82H1htWdFiwBZR9R_VbvGWkRViaCElk48nz55PwPeAVreb4dptjjtuT30PIHN2GvNJUTuypmttyCzXHSO6L-KCNAXWZ_7sIHaNMCpoQtKgLegQIExAB&biw=393&bih=656&dpr=3
|
||||
---
|
||||
Buying a security solution unprepared? You're probably in violation of ISO 27001 clause 8.1
|
||||
|
||||
---
|
||||
On labeling email
|
||||
|
||||
https://www.reddit.com/r/ISO27001/s/kOPJtzxOtM
|
||||
---
|
||||
**'Eigenaarschap' is een populair begrip onder managers. Maar wat is het? En hoe krijg je het? - NRC**
|
||||
|
||||
https://www.nrc.nl/nieuws/2025/09/24/eigenaarschap-is-een-populair-begrip-onder-managers-maar-wat-is-het-en-hoe-krijg-je-het-a4907321
|
||||
---
|
||||
**Publish control sets for selected business processes (Gerard Blokdyk approach)**
|
||||
|
||||
- Reviewing GDPR Processing Agreements? These are the relevant ISO 27002 controls:
|
||||
- Business Continuity Plan? Apply the following controls to stay compliant: These are the relevant ISO 27002 controls:
|
||||
- etc.
|
||||
- Writing a policy on Remote Working?
|
||||
- Posture management?
|
||||
- Vendor selection and due dilligence?
|
||||
- Auditing HR security:
|
||||
- Supporting remote work
|
||||
- Supply Chain Security
|
||||
- Secure Software Development
|
||||
- Outsourcing development
|
||||
- Preventing data breaches (termination of cloud services + configuration management)
|
||||
- Checklist for Cloud Services agreement - 27002:2022 5.23 Information security for use of cloud services
|
||||
|
||||
#iso27001 #compliant_working <- this needs a better hashtag
|
||||
|
||||
---
|
||||
Create a list of Weird hacker words:
|
||||
- Burp attacks
|
||||
- Smurf attacks
|
||||
- Digital Dumpster Diving and google dorking.
|
||||
---
|
||||
Publish about Stop Ransomware
|
||||
|
||||
https://www.cisa.gov/stopransomware
|
||||
---
|
||||
NIST Seeks Information on Chinese Participation in the International Standards Development Process
|
||||
|
||||
https://www.nist.gov/news-events/news/2021/11/nist-seeks-information-chinese-participation-international-standards
|
||||
---
|
||||
Software risks in private equity buyouts | Synopsys
|
||||
|
||||
https://www.synopsys.com/blogs/software-security/software-risks-private-equity-buyouts/
|
||||
---
|
||||
How safe is it to use a Github Action contributed by a third party?
|
||||
|
||||
https://security.stackexchange.com/questions/256790/how-safe-is-it-to-use-a-github-action-contributed-by-a-third-party
|
||||
|
||||
---
|
||||
|
||||
# Content Scratch File
|
||||
|
||||
`Write to Express, not to Impress`
|
||||
`Write like you Speak`
|
||||
|
||||
#TSW
|
||||
|
||||
|
||||
|
||||
[[Risk analysis is useless]]
|
||||
|
||||
[KuppingerCole’s practical implications of NIS2](bear://x-callback-url/open-note?id=4DC76555-BF6E-4B99-8260-EF99344D5F3F)
|
||||
|
||||
Seven Dimensions of Security Culture - see Obsidian note
|
||||
|
||||
- Illuminated by awareness
|
||||
- The CISO’s blind spot: Actual human behaviour
|
||||
- What happens on the workfloor, stays on the workfloor
|
||||
- Ransomware is the boogie man – als je over bewustzijn en gedrag praat, begint men meestal over phishing links en ransomware. Maar het echte gevaar zit in de werkprocessen
|
||||
- En hoeveel incidenten of bijna incident zijn er niet gemeld? Bij CM bespreek je dat in de geborgenheid van je eigen team
|
||||
- Driehoek patiëntveiligheid, medewerkerveiligheid, informatieveiligheid
|
||||
- De effectiviteit / het rendement van het ISMS vergroten
|
||||
* Security: making it chefsache (met Gilbert van Z.)
|
||||
* Cybersecurity requires behavioral change
|
||||
* How CMIS works with ISO 27001
|
||||
* Risk Management under ESG/CSRD - see [note](bear://x-callback-url/open-note?id=9EFE612A-3AE3-4AA5-B7EC-016573722C21)
|
||||
* Working with multiple teams
|
||||
* Integrating CMIS with existing management systems and frameworks
|
||||
* Bridging the gap with non-technical departments
|
||||
* Risk based vs control driven
|
||||
* Build in Public/Indiehackers: I was going to build software and now it’s a set of PDF’s
|
||||
* Build in Public/Indiehackers: Restrictive domain names and pivoting
|
||||
* My Risk, Your Control / Now it’s your risk / Bystander effect and IS
|
||||
* Theory of Planned Behavior
|
||||
* Pushing Security Management to the Left
|
||||
* Security should be a basic hygiene factor in every team
|
||||
* [Theory of Planned Behavior](https://en.wikipedia.org/wiki/Theory_of_planned_behavior)
|
||||
* Twee blinde vlekken: de CISO maakt zich zorgen over de blinde vlek van de medewerkers (ze kennen de risico’s niet), maar heeft zelf een blinde vlek voor risico’s in de operatie.
|
||||
|
||||
“Het is voor mensen gemakkelijk kwetsbaarheden te veroorzaken waarvan wij niet op de hoogte zijn. Je moet een manier vinden om goede input te verzamelen, om te weten dat alles procesmatig OK is”. Marco Biekaert (?), Belastingdienst BCM:
|
||||
|
||||
Cyber from cybernetics, a scientific field studying systems with a feedback- and control-loop in which technology and human work together towards a goal.
|
||||
# What is wrong in InfoSec?
|
||||
* Mensen noemen risico en verwachten vervolgens dat iemand anders het oplost
|
||||
* Informatie veiligheid is het probleem van de IT afdeling, Of: daar zorgt de IT afdeling toch voor
|
||||
* De compliance afdeling is een beleidsfabriek
|
||||
* Richtlijnen worden niet gevolgd omdat het risico veel lager wordt ingeschat of de middelen tussen de persoon en zijn doel staan: ze werken beperkend
|
||||
* We weten dat het speelt maar toch niet bij ons
|
||||
* Ja dat zeggen wij al jaren
|
||||
|
||||
|
||||
Typical InfoSec awareness training
|
||||
|
||||
That guy from IT during your onboarding class:
|
||||
|
||||
#
|
||||
|
||||
---
|
||||
|
||||
**Risk analysis is useless**
|
||||
|
||||
the cornerstone metrics for actuary modelers — the Annual Loss Expectancy and Annual Rate of Occurrence — with a high degree of accuracy is beyond the current capabilities -> are historical and says little about the future.
|
||||
|
||||
|
||||
The traditional actuary models do not apply well to an environment where highly motivated, creative, and intelligent attackers are dynamically pursuing actions that cause insurable events.
|
||||
|
||||
The problem is with the nature of the threat. Cyber attackers escalate and adapt quickly, which undermines the historical-based models that insurance companies rely on. Attackers are continually shifting their maneuvers that identify victims, cause increasing loss, and rapidly shift to new areas of impact.
|
||||
Denial of service attacks were once popular but were superseded by data breaches, which cause much more damage. Recently, attackers expanded their repertoire to include ransomware-style attacks that increased the insurable losses ever higher.
|
||||
|
||||
|
||||
---
|
||||
|
||||
# Human Error Breaches Incidents
|
||||
|
||||
### NL Healthcare / Orthopedium
|
||||
- Orthopedium: sinds software update kunnen de röntgenscanner en het EPD niet meer met elkaar overweg: het patiëntnummer moet opgezocht worden in het EPD en handmatig worden ingegeven in de software van de röntgenscanner
|
||||
- Orthopedium: de werkstations in de OK starten heel traag op. De afdelingssecretaresse heeft de inloggegevens van alle artsen in haar agenda, en logt ze ‘s ochtends alvast in. & de operatieploegen rouleren gedurende de dag over de OK’s, maar loggen niet opnieuw in. De verrichtingen zijn daardoor gekoppeld aan de verkeerde arts. Dit wordt achteraf handmatig gecorrigeerd aan de hand van de planning van die dag.
|
||||
|
||||
### NZA
|
||||
- NZA: de onbeheerde netwerkmap voor de vakantiefoto’s, waar iedereen met een NZA-account bij kon, werd al snel ontdekt als plek om gemakkelijk grote dossiers en bestanden met elkaar te delen. Meestal werden die daarna niet verwijderd.
|
||||
|
||||
### Prestige Data Breach
|
||||
- [Prestige Data Breach](https://rkranendonk.medium.com/learning-points-from-the-prestige-data-breach-eac454b577d3)
|
||||
- Slechte architectuur: manipulatie van tekstbestanden op een file systeem i.p.v. een robuuste database
|
||||
- Publieke / te ruime toegang AWS Bucket door slechte configuratie of Free Tier (bijv. Miro)
|
||||
- Niet toepassen encryptie
|
||||
- Gegevens langer bewaren dan nodig
|
||||
- Meer gegevens verwerken dan nodig
|
||||
- In productie nemen van PoC oplossing
|
||||
|
||||
### Junis
|
||||
- Versleuteld mailen werkt niet bij alle ketenpartners – het beleid is om gegevens over kinderen en ouders alleen versleuteld naar de samenwerkingspartners te mailen. Bij sommige ontvangers werkte het ontsleutelen van de mail niet goed, door een afwijkende configuratie van de mailserver.
|
||||
- Communicatie met ouders via WhatsApp – want het lukt niet alle ouders om de speciale app te installeren
|
||||
- Deurcodes pand worden aan ouders gegeven
|
||||
- Sleutels worden meegegeven aan externe onderhoudsmonteurs
|
||||
- Werken met beperkt aantal voorkeursleveranciers vergroot de afhankelijkheid
|
||||
- Ontbrekende of onvolledige verantwoording subsidieaanvraag onder tijdsdruk
|
||||
- Onvoorziene consequenties van eigen veranderingen en handelen voor andere afdelingen
|
||||
- Onvoorziene consequenties van veranderingen en handelen andere afdelingen voor ons
|
||||
- Minder mogelijkheden voor handmatig ingrijpen door toegenomen integratie
|
||||
- Niet tijdige of incorrecte mutatie in AFAS betekent geen toegang tot de juiste informatie op Intranet voor medewerker cluster
|
||||
- Verkeerde mdw/locatie in Quebble door onjuiste KP in AFAS/HR; kwaliteit roostering gaat omlaag
|
||||
- Makkelijk bestellen zonder verder gedoe Verantwoordelijkheid correcte invoer verschuift: risico op foute invoer
|
||||
- Kinderopvangtoeslag Problemen door ontbreken noodzakelijke kennis bij ouders
|
||||
- Ondersteuning te weinig beschikbaar, onduidelijkheid waar je terecht moet (IT of FAB)
|
||||
- Verzenden cadeaus gastouders door derden vraagt om verstrekking NAW-gegevens
|
||||
- Indeling gegevens in verschillende bronsystemen matchen niet
|
||||
- Gevoelige informatie publiceren op verkeerde plek op SharePoint (wegens onduidelijke structuur en ontbreken aan instructies
|
||||
- Onvoldoende bewustzijn bij mdws over de toegankelijkheid van verschillende sites op Intranet en SharePoint
|
||||
- Weekberichten worden niet opgeslagen in Groepssites, maar in Clustersites, waar ook gevoelige informatie kan staan zoals ontruimingsplannen
|
||||
- PM’ers hebben privé telefoons en geen Office365 licentie. Hoe moeten ze Teams Chat gebruiken als WhatsApp niet mag? En communicatie met ouders kan ook niet via Teams.
|
||||
- Alle medewerkers met privemail-adres in CC personeelsnieuwsbrief
|
||||
- Gevoelige informatie wordt verstuurd naar privé adressen, bijv. in Weekbericht
|
||||
- Op een telefoon kun je Teams openen zonder in te loggen – unlock telefoon is genoeg
|
||||
- Gebruik beelden van kinderen niet mogelijk door niet aanleveren toestemmingsformulieren door PM'ers
|
||||
- Werken met iPads: invullen formulieren online werkt n iet goed, dan maar mailen naar huisadres en terug.
|
||||
- Zeer groot dienstverleners-landschap!
|
||||
- Gevoelige info besprekingen op vergaderbordjes / Onderwerp bespreking uit Outlook kan gevoelige info bevatten
|
||||
- PM’er maakt WhatsApp groepje aan voor ouders – niet alle ouders zijn er blij mij dat hun tel.nr. nu voor iedereen zichtbaar is
|
||||
- Secretariaat: Kans op insluipers wegens ontbreken sluitronde door beveiligingsfirma
|
||||
|
||||
|
||||
### Parnassia groep
|
||||
- In EPD kan niet gezocht worden op BSN, daardoor wordt gezocht op andere kenmerken. Gevolg is dat patiënten dubbel worden ingeschreven, en behandelingen/afspraken aan de verkeerde patient gekoppeld worden
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
|
||||
Vastgelopen met je ISO 27001 implementatie? Komt je SIO 27001 implementatie niet van de grond? Ik kan je helpen
|
||||
|
||||
Wie moet je erbij betrekken?
|
||||
Wie moet je verantwoordelijk maken?
|
||||
Hoeveel tijd moet je vrijmaken?
|
||||
Welke tooling is nodig
|
||||
Moet jhe een consultant inhuren ?
|
||||
Wie maak je projectmanager?
|
||||
Waar moet je beginnen?
|
||||
Moet je alle controls implementeren?
|
||||
Loopt de boel niet vast in eindeloze procedures?
|
||||
Wordt het niet veel te bureacratisch
|
||||
Mensen szien de noodzaak niet
|
||||
IT werkt tegen
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
|
||||
1. Titel: Waarom een ISO 27001 audit?
|
||||
* wat is ISO 27001?
|
||||
* wat heb je aan een certificaat?
|
||||
* wat zijn redenen waarom je gecertificeerd zou willen zijn?
|
||||
* wat voor voordelen biedt dat?
|
||||
2. Ben ik klaar voor de audit?
|
||||
3. Hoe lang duurt een audit, en wat kost het?
|
||||
4. Hoe vraag je een audit aan?
|
||||
5. Hoe verloopt een audit?
|
||||
6. Wat verwacht de Auditor?
|
||||
7. Wat is het resultaat van de audit?
|
||||
8. Uitslag en Certificering
|
||||
9. Afsluiting met verwijzing naar ISO27DIY, incl. link met UTM-tracker
|
||||
|
|
@ -0,0 +1,187 @@
|
|||
# Alles wat je wilt weten over de ISO 27001 audit
|
||||
#iso27DIY/marketing/content
|
||||
|
||||
Dit boekje is een gids om je door het volledige audit- en certificeringsproces te loodsen, van het leggen van het fundament tot de uiteindelijke uitreiking van het certificaat.
|
||||
|
||||
## Waarom een ISO 27001 audit?
|
||||
|
||||
ISO 27001 is de internationale standaard voor informatiebeveiliging. Het behalen van deze certificering bewijst dat jouw organisatie informatiebeveiliging serieus neemt en structureel beheert via een Information Security Management System (ISMS).
|
||||
## Wanneer ben ik klaar voor de audit?
|
||||
|
||||
Een organisatie is klaar voor de initiële certificeringsaudit wanneer het fundament van het Information Security Management System (ISMS) niet alleen is geïmplementeerd, maar ook door de organisatie zelf is getoetst op de effectieve werking ervan [1].
|
||||
|
||||
Concreet betekent dit dat de volgende stappen minimaal moeten zijn afgerond voordat de externe auditor langskomt voor de eerste fase van de audit (de Stage 1 documentatie-audit):
|
||||
|
||||
* **Volledige implementatie van het ISMS:** De fundamentele processen uit de norm (hoofdstuk 4 tot en met 10) moeten operationeel zijn [1, 2]. Dit houdt in dat de scope is afgebakend, het informatiebeveiligingsbeleid is ondertekend en een volledige risicoanalyse is uitgevoerd en vertaald naar een risicobehandelplan [3].
|
||||
* **Een afgeronde Interne Audit:** Voordat de externe audit begint, vereist de norm dat je het systeem zelf hebt geëvalueerd. Je moet op zijn minst één interne audit hebben uitgevoerd en hier een auditrapport van hebben opgeleverd [1, 4]. Het is hierbij best practice dat deze eerste interne audit direct de volledige scope van jouw ISMS beslaat [4]. Ook moeten eventuele afwijkingen die tijdens de interne audit zijn gevonden, correct zijn gedocumenteerd in actieplannen (follow-up) [4].
|
||||
* **Uitgevoerde Directiebeoordeling (Management Review):** Na de interne audit moet het topmanagement (de directie) formeel de prestaties en de effectiviteit van het ISMS hebben beoordeeld [1, 5]. Dit is cruciaal om managementbetrokkenheid aan te tonen, wat een harde eis is voor het fundament [3].
|
||||
* **De Verplichte Documentatie is Beschikbaar:** Zoals we eerder bespraken in de context van de vier documentatieniveaus, moeten de belangrijkste documenten zoals je Verklaring van Toepasselijkheid (Statement of Applicability), procedures en de registraties (records) van de hierboven genoemde audits en management reviews aanwezig zijn en goed worden beheerd [6, 7].
|
||||
|
||||
Kort samengevat: Zodra je het managementsysteem hebt geïmplementeerd én je de zogenaamde 'Plan-Do-Check-Act' cyclus minimaal één keer zelf hebt rondgemaakt door het uitvoeren van een interne audit en management review, is de organisatie klaar om een onafhankelijke certificatie-instelling (certification body) te selecteren en de externe audit aan te vragen [1].
|
||||
|
||||
### Waarom het fundament eerst moet
|
||||
Een ISMS bestaat uit twee hoofddelen: een procesmatig fundament (clausules 4 tot en met 10 van de norm) en een lijst met 93 mogelijke beveiligingsmaatregelen (de Annex A controls). Het is een vereiste om de fundamentele processen eerst volledig te hebben geïmplementeerd [1]. Deze processen dwingen je namelijk om een risicoanalyse uit te voeren, zodat je weet wát je moet beveiligen [2]. Je bent niet verplicht om alle 93 Annex A maatregelen blindelings te implementeren; je kiest ze uit op basis van jouw specifieke risico's en documenteert deze in de Verklaring van Toepasselijkheid (Statement of Applicability of SoA) [3, 4].
|
||||
|
||||
Zorg ook dat de **scope** van je ISMS en wat precies gecertificeerd moet worden helder in het ‘Scope Statement’ staat.
|
||||
|
||||
Dit onderscheid tussen het fundament (het managementsysteem) en de specifieke maatregelen zie je terug in de opbouw van de audit:
|
||||
|
||||
In Stage 1 kijkt de auditor nog niet naar specifieke beveiligingsmaatregelen, maar uitsluitend naar het ontwerp van het managementsysteem. Hier gaat het om fundamentele vereisten: begrijpt de organisatie de standaard, is de scope duidelijk, is de risicoanalyse uitgevoerd, en zijn de fundamentele processen zoals de interne audit en de directiebeoordeling (management review) afgerond.
|
||||
|
||||
Pas in Stage 2 duikt de auditor echt de praktijk in om de effectiviteit en implementatie van het ISMS en de specifieke maatregelen (de controls) te evalueren.
|
||||
|
||||
|
||||
### Mag ik certificeren als nog niet alles perfect is?
|
||||
**Ja, met een belangrijke nuance.** Een auditor verwacht niet dat vanaf dag één elke beveiligingsmaatregel 100% is doorgevoerd. Zolang het managementfundament (zoals risicoanalyses, interne audits en directiebeoordelingen) draait, accepteert de norm dat je met een risicobehandelplan werkt. Als een bepaalde maatregel pas later wordt geïmplementeerd en de directie accepteert in de tussentijd formeel het restrisico, is dat toegestaan [5, 6]. Zorg er echter voor dat de *Verklaring van Toepasselijkheid* altijd de realiteit weerspiegelt en je niet claimt dat iets effectief is, terwijl het eigenlijk nog op de roadmap staat [4, 7].
|
||||
|
||||
## Wat kost een ISO 27001-audit en hoe lang duurt deze?
|
||||
|
||||
De prijs wordt meestal bepaald door **organisatiegrootte, complexiteit, aantal locaties, bestaande controles en de auditdagen** die nodig zijn. Een certificeringsinstantie rekent vaak per auditdag, en day rates liggen in de bronnen grofweg rond **€1.200–€1.800 in Europa** of vergelijkbaar in andere valuta. Als je al een goed ISMS en veel bewijs hebt, valt de audit meestal goedkoper uit dan wanneer alles nog opgezet moet worden.[2][4][5][1]
|
||||
|
||||
De totale kosten van een audit hangen sterk af van de gekozen certificeringsinstantie, de complexiteit van je organisatie en het aantal benodigde auditdagen. Voor een **initiële ISO 27001-audit** kun je grofweg rekenen op **€5.000 tot €10.000** voor een kleine organisatie, en vaak **€10.000 tot €20.000** voor middelgrote bedrijven. Sommige Nederlandse bronnen noemen voor de EU en Nederland ook totale certificeringsfees van ongeveer **€6.000 tot €12.000**, afhankelijk van de scope en het gehanteerde dagtarief. Voor micro-businesses en heel kleine teams worden in recente bronnen ook lagere auditfees genoemd, variërend van ongeveer **€800 tot €3.000** (omgerekend), al is dit sterk afhankelijk van de specifieke certificatie-instelling.
|
||||
Dat deze kosten kunnen variëren, komt doordat het aantal dagen dat een auditor in rekening brengt niet zomaar wordt verzonnen. Dit wordt strikt gereguleerd door tabellen uit de **ISO 27006-norm**, waardoor de geoffreerde tijdsbesteding tussen verschillende instellingen vaak redelijk overeenkomt.
|
||||
**De basislijn voor het aantal auditdagen** Het startpunt voor de berekening van de audittijd is altijd de grootte van de organisatie (het aantal FTE):
|
||||
* **1 tot 10 medewerkers:** Hiervoor staat een absoluut minimum van **5 auditdagen** in totaal.
|
||||
* **11 tot 15 medewerkers:** De basislijn stijgt naar **6 auditdagen**.
|
||||
* **Grotere organisaties (bijv. 176 tot 275 medewerkers):** De basislijn bedraagt in dit geval **14 auditdagen**.
|
||||
|
||||
⠀**Hoe worden deze dagen in de praktijk verdeeld?** De auditdagen omvatten meer dan alleen de uren dat de auditor daadwerkelijk bij jou op kantoor is. Voor de minimale audit van 5 dagen (voor het kleinste MKB) ziet de standaard verdeling er doorgaans als volgt uit:
|
||||
* **Een halve dag:** Voorafgaande planning en voorbereiding.
|
||||
* **1 volledige dag:** De Stage 1 audit (de documentatie-audit).
|
||||
* **3 volledige dagen:** De Stage 2 audit (de gedetailleerde on-site of remote implementatie-audit).
|
||||
* **Een halve dag:** Het opstellen en schrijven van het uiteindelijke auditrapport.
|
||||
|
||||
⠀**Aanvullende factoren die kosten en tijd beïnvloeden** Hoewel het aantal medewerkers de basislijn vormt, kan de certificatie-instelling de uiteindelijke audittijd (en daarmee de prijs) naar boven of beneden bijstellen op basis van specifieke factoren. De instelling beoordeelt onder andere:
|
||||
* **Sector en complexiteit:** Werkt de organisatie in een hoogrisico- of streng gereguleerde sector (zoals de gezondheidszorg), dan is er meer audittijd nodig.
|
||||
* **Aantal locaties:** Hoeveel fysieke vestigingen of kantoren vallen er binnen de audit-scope?
|
||||
* **IT-omgeving:** Bestaat de IT uit één overzichtelijke technologiestack, of is het een complexe omgeving met meerdere integraties?
|
||||
* **Outsourcing:** Hoeveel diensten of processen zijn uitbesteed aan externe leveranciers?
|
||||
* **Wet- en regelgeving:** Zijn er specifieke wettelijke vereisten waaraan getoetst moet worden?
|
||||
|
||||
Hoewel de berekening van het *aantal auditdagen* streng genormeerd is, kunnen de totale kosten desondanks toch sterk kunnen afhangen van de gekozen instantie. Dit heeft te maken met de volgende variabelen:
|
||||
* **Dagtarieven en reputatie:** Hoewel de auditdagen gelijk zijn, stelt elke certificeringsinstantie haar eigen commerciële dagtarieven vast. Deze prijzen variëren onder andere op basis van hun reputatie en marktpositie.
|
||||
* **Berekeningswijze en inbegrepen tijd:** In de certificatieovereenkomst wordt vastgelegd hoe de vergoedingen precies worden berekend. Het kan per instantie verschillen wat er wel of niet exact onder de gefactureerde 'audittijd' valt en hoe extra werkzaamheden in rekening worden gebracht.
|
||||
* **Reis- en verblijfkosten (logistiek):** Alle kosten rondom de uitvoering van de audit moeten door de te auditen organisatie worden betaald. Een certificeringsinstantie die auditors lokaal of dichtbij beschikbaar heeft, zal aanzienlijk goedkoper uitvallen dan een instantie die auditors van ver moet laten invliegen of hoge verblijfkosten rekent.
|
||||
* **Mogelijkheid tot gecombineerde audits:** Sommige instanties kunnen de audit combineren met andere normen (zoals ISO 9001 of lokale kaders). Het uitvoeren van zo'n gecombineerde audit kan de organisatie over het algemeen tijd en geld besparen.
|
||||
* **Inschatting van complexiteit:** Hoewel de basis voor het minimum aantal auditdagen in tabellen is vastgelegd, moet de instantie dit aantal verhogen of verlagen op basis van specifieke factoren, zoals de complexiteit van de technologie, het aantal fysieke locaties, wettelijke eisen en de mate van outsourcing. Hoe de instelling deze weging en de complexiteit van de organisatie precies inschat, is maatwerk en beïnvloedt de uiteindelijke prijs.
|
||||
|
||||
**Bijkomende kosten**
|
||||
De auditfee is niet je totale kostenplaatje. Vaak komen daar nog **consultancy, implementatietijd, tooling, documentatie en interne uren** bij, waardoor de totale eerstejaarskosten veel hoger kunnen uitvallen dan alleen de audit. Sommige recente overzichten noemen totalen van ongeveer **€10.000 tot €50.000** voor kleine tot middelgrote organisaties als je alles meerekent.[5][7][1]
|
||||
|
||||
**Tip voor het aanvragen van offertes:** Bij het beoordelen van wat de audit gaat kosten, is het essentieel om niet alleen naar het totale bedrag onderaan de streep te kijken. Controleer ook goed in de overeenkomst wat het dagtarief is, wat er wel en niet wordt meegerekend, en hoe de auditdagen precies zijn verdeeld over de planning, Stage 1, Stage 2 en de rapportage.
|
||||
|
||||
### Jaarlijkse kosten
|
||||
|
||||
Na de eerste certificering komen er meestal **surveillance audits** bij, die vaak goedkoper zijn dan de initiële audit. In de bronnen zie je hiervoor vaak bedragen van ongeveer **30% tot 50% van de initiële auditkosten**, of ruwe bandbreedtes van **€2.000–€5.000 per jaar** voor kleinere organisaties. Om de drie jaar volgt dan een hercertificeringsaudit die weer dichter bij de initiële audit kan liggen.[6][1]
|
||||
|
||||
|
||||
Sources
|
||||
[1] Hoeveel kost een ISO 27001-certificering in 2026? - ISOPlanner https://isoplanner.app/nl/hoeveel-kost-een-iso-27001-certificering-in-2026/
|
||||
[2] ISO 27001 Certification Costs FAQ - High Table https://hightable.io/iso-27001-certification-costs-faq/
|
||||
[3] ISO 27001 Certification Cost [2026 update] - High Table https://hightable.io/iso-27001-certification-cost/
|
||||
[4] ISO 27001 Cost: What Businesses Need to Know - GRC Solutions https://grcsolutions.io/iso27001-certification-costs/
|
||||
[5] How Much Does ISO 27001 Certification Cost? - Steerlab https://www.steerlab.ai/blog/iso-27001-certification-cost
|
||||
[6] How much does ISO 27001 certification cost? | Blog - OneTrust https://www.onetrust.com/blog/iso-27001-certification/
|
||||
[7] How Much Does ISO 27001 Certification Cost in 2026? - StrongDM https://www.strongdm.com/blog/iso-27001-certification-cost
|
||||
[8] What does ISO 27001 certification cost? - Fendix https://www.fendix.nl/en/resources/wat-kost-een-iso-27001-certificering
|
||||
[9] ISO27001 Cost - Reddit https://www.reddit.com/r/ISO27001/comments/1lh3lwx/iso27001_cost/
|
||||
[10] ISO 27001 certification costs - Dekra https://www.dekra.nl/en/iso-27001-certification-costs/
|
||||
|
||||
## Hoe vraag je een audit aan?
|
||||
Je vraagt een audit voor **ISO 27001-certificering** aan bij een geaccrediteerde certificeringsinstantie, niet bij een normale consultant of een interne auditor. De route is meestal: eerst intern voorbereiden en eventueel een pre-audit/readiness check doen, daarna de formele certificeringsaudit aanvragen bij een certificatiebureau.[1][2][3]
|
||||
|
||||
### Bij wie vraag je het aan
|
||||
|
||||
Je vraagt het aan bij een **certification body / certificeringsinstantie** die geaccrediteerd is voor ISO 27001. Voorbeelden die in Nederlandse overzichten genoemd worden zijn onder andere Kiwa, DNV, BSI en DigiTrust, maar je moet altijd controleren of ze op dit moment echt geaccrediteerd zijn voor ISO 27001. Consultants kunnen je wel helpen met voorbereiding of interne audit, maar zij geven meestal niet zelf de officiële certificering af.[3][4][5][1]
|
||||
|
||||
### Hoe je het aanvraagt
|
||||
|
||||
Meestal vraag je een **offerte of auditvoorstel** aan via het sales- of contactformulier van de certificeringsinstantie. Ze willen dan meestal weten: hoeveel medewerkers je hebt, welke locaties en systemen in scope zijn, of je al een ISMS hebt, welke bestaande certificeringen je hebt, en wanneer je de audit wilt laten plaatsvinden. Daarna plannen ze doorgaans de Stage 1-audit en Stage 2-audit in.[6][7]
|
||||
|
||||
### Waar je op moet letten
|
||||
|
||||
Niet elke partij die “ISO 27001 audit” zegt, mag ook de officiële certificering afgeven. Voor de echte certificeringsaudit moet de partij geaccrediteerd zijn; dat is belangrijker dan alleen een mooie website of een snelle prijsopgave. Ook is het verstandig om een partij te kiezen die ervaring heeft met jouw type organisatie, zodat de audit niet onnodig abstract of bureaucratisch wordt.[2][5][7][8][9]
|
||||
|
||||
Als je wilt, kan ik hierna ook een korte mailtemplate maken waarmee je direct een offerte voor een ISO 27001-audit aanvraagt.
|
||||
|
||||
Sources
|
||||
[1] Wat is de ISO 27001 audit: Checklist, praktische tips en de ... https://certificeringsadvies.nl/hoe-gaat-een-iso-27001-audit-in-zijn-werk/
|
||||
[2] Certification Process - ISO 27001 Documentation - GRC Lab https://grclab.com/iso27001-docs/certification-process
|
||||
[3] A breakdown of the ISO 27001 audit and certification process https://www.thoropass.com/blog/iso-27001-audit-certification-process
|
||||
[4] Lijst Van Iso 27001-geaccrediteerde Certificeringsinstanties https://www.online-iso.nl/iso-14001/lijst-van-iso-27001-geaccrediteerde-certificeringsinstanties/
|
||||
[5] Overzicht certificatie instellingen - ISO Register https://isoregister.nl/overzicht-certificatie-instellingen/
|
||||
[6] ISO 27001 Audit: How to prepare and the critical next steps - UpGuard https://www.upguard.com/blog/iso-27001-audit-next-steps
|
||||
[7] ISO 27001 Certification Audit 2026: Requirements, Costs & Timeline https://www.icertworks.com/iso-27001-certification-audit-in-2026-requirements-costs-timeline-what-auditors-look-for/
|
||||
[8] ISO 27001 Certification vs Accreditation - What You Need to Know ... https://www.ocden.com/compliance/iso-accrediation-certification-auditor
|
||||
[9] Examining Certification Bodies for ISO 27001 Certification - A-LIGN https://www.a-lign.com/articles/blog-examining-certification-bodies-iso-27001
|
||||
[10] Overzicht ISO 27001 certificering en implementatie bedrijven ... https://obi.nl/iso-27001-certificering/
|
||||
|
||||
## De Tweefasen-Audit
|
||||
|
||||
Wanneer je besluit voor certificering te gaan door een onafhankelijke externe instantie (een zogenaamde 'third-party audit'), wordt de initiële audit altijd opgesplitst in twee fases [8, 9].
|
||||
|
||||
### Stage 1: De Documentatie-audit
|
||||
Tijdens de Stage 1 audit verifieert de auditor nog niet de effectiviteit van de maatregelen in de praktijk, maar controleert hij of zij het *ontwerp* van het management systeem [9]. De auditor neemt de gedocumenteerde informatie door, zoals het beveiligingsbeleid, de doelstellingen, en kijkt of de interne audit en directiebeoordeling zijn uitgevoerd [9, 10]. Dit neemt meestal zo'n 30% van de totale audittijd in beslag [11].
|
||||
|
||||
### De Tussenpauze
|
||||
Tussen Stage 1 en Stage 2 zit doorgaans een pauze van twee tot vier weken, waarbij een maximum van twaalf weken geldt [12, 13]. Deze pauze geeft jouw organisatie de kans om eventuele zorgpunten uit Stage 1 te verhelpen voordat het echte veldwerk begint [14].
|
||||
|
||||
### Stage 2: De Gedetailleerde Implementatie-audit
|
||||
In Stage 2 duikt de auditor echt in de organisatie (vaak op locatie of remote) om te evalueren of de beveiligingsmaatregelen daadwerkelijk zijn geïmplementeerd en effectief werken [9, 15, 16]. In deze fase worden systemen bekeken en interviews met medewerkers gehouden.
|
||||
|
||||
---
|
||||
|
||||
## Wat Verwacht de Auditor (en hoe toon je dat aan)?
|
||||
|
||||
### Hoe stelt een auditor vragen?
|
||||
Tijdens Stage 2 wil de auditor achterhalen hoe processen écht werken. Je kunt de volgende technieken verwachten:
|
||||
* **Open interviews:** Auditors stellen zelden ja/nee vragen om te voorkomen dat ze het antwoord beïnvloeden (geen 'leidende vragen'). Verwacht vragen als: *"Kun je me uitleggen hoe jullie benadering van back-ups werkt?"* [17-19].
|
||||
* **Systeemspecifieke vragen:** Na een algemene uitleg zal de auditor inzoomen. *"Je hebt zojuist de procedures uitgelegd, kun je me vertellen hoe je dit toepast op systeem X?"* [20].
|
||||
* **"Laat het me zien" (Technische verificatie):** Mondeling (verbaal) bewijs is de zwakste vorm van auditbewijs [21, 22]. Een auditor zal na een interview vaak om demonstraties vragen. Dit betekent dat hij/zij met je meekijkt in de systeemconfiguraties (bijvoorbeeld firewall-regels of encryptie-instellingen) om het verbale verhaal met de technische realiteit te bevestigen [23-25].
|
||||
|
||||
### Wat voor documentatie is vereist?
|
||||
Hoewel je niet voor alles gigantische boekwerken hoeft te schrijven, kijkt een auditor in vier logische lagen naar je documentatie [26]:
|
||||
1. **Strategisch (Niveau 1):** Documenten ondertekend door het management, zoals het ISMS-beleid, de scope en de Verklaring van Toepasselijkheid (SoA) [26, 27].
|
||||
2. **Risicobeheer (Niveau 2):** Het formele proces: hoe voer je risicoanalyses uit en hoe behandel je risico's? [28].
|
||||
3. **Procedures (Niveau 3):** Hoe specifieke maatregelen worden uitgevoerd (bijv. wachtwoordbeheer, patchmanagement) [29].
|
||||
4. **Records (Niveau 4):** Het keiharde bewijs. Dit zijn systeemlogs, incidententickets en notulen van vergaderingen die bewijzen dat het proces écht is gevolgd [30-32].
|
||||
|
||||
|
||||
## Wat is het resultaat van de audit? – Auditbevindingen en Het Correctieplan
|
||||
|
||||
Als een auditor vaststelt dat niet aan een eis van de norm wordt voldaan, resulteert dit in een auditbevinding. Er zijn verschillende classificaties:
|
||||
|
||||
* **Observaties / Anomalieën:** Punten voor verbetering of heel kleine incidentele afwijkingen die het management systeem als geheel niet in gevaar brengen [33, 34].
|
||||
* **Kleine Non-conformiteit (Minor):** Een gedeeltelijk falen van een eis. Dit werpt enige twijfels op, maar het brengt het vermogen van het ISMS om zijn doelen te bereiken niet in gevaar [35, 36].
|
||||
* **Grote Non-conformiteit (Major):** Een volledig falen van een eis of een onacceptabel risico. Bij een Major non-conformiteit wordt de certificering direct gepauzeerd [37, 38].
|
||||
|
||||
### Het opstellen van een Corrective Action Plan (CAP)
|
||||
Als er non-conformiteiten zijn vastgesteld, moet jouw organisatie een gestructureerd actieplan indienen bij de auditor [39]. Vaak krijg je **10 tot 60 dagen** de tijd om dit in te dienen [40]. Zonder ingediend actieplan volgt er geen certificeringsaanbeveling [40].
|
||||
Dit plan moet per non-conformiteit het volgende bevatten [39, 41]:
|
||||
1. **De Root Cause Analyse:** Een analyse van de kernoorzaak (waarom gebeurde dit?).
|
||||
2. **Correcties:** De pleister op de wond (hoe hebben we de directe tekortkoming nu tijdelijk opgelost?).
|
||||
3. **Correctieve Acties:** De structurele langetermijnoplossing (hoe zorgen we dat dit nooit meer gebeurt?).
|
||||
4. **Realistische Tijdslijnen:** Wanneer is dit voltooid?
|
||||
|
||||
### Wat als je het oneens bent met de auditor?
|
||||
Het is de taak van de leidende auditor om eventuele meningsverschillen tijdens de audit of in de afsluitende bijeenkomst uit te praten [42, 43]. Kom je er echt niet uit en weiger je de bevindingen te accepteren? Dan heb je altijd het recht om de conclusies niet te accepteren en een formeel klachten- of beroepsproces (appeal) op te starten bij de certificatie-instelling [44, 45].
|
||||
|
||||
---
|
||||
|
||||
## De Uitslag en Certificering
|
||||
|
||||
### De Aanbeveling
|
||||
Aan het einde van de Stage 2 audit (vaak tijdens de closing meeting) zal de auditor zijn conclusies met het management bespreken [46]. De auditor kan **vier mogelijke aanbevelingen** doen [47, 48]:
|
||||
1. **Aanbeveling voor certificering:** Alles is in orde.
|
||||
2. **Voorwaardelijke aanbeveling zónder extra bezoek:** Je krijgt het certificaat, mits je op afstand een goedgekeurd actieplan voor je (kleine) non-conformiteiten aanlevert.
|
||||
3. **Voorwaardelijke aanbeveling mét extra bezoek:** Er is een follow-up audit op locatie nodig om de herstelwerkzaamheden fysiek te bewijzen (vaak bij een *Major*).
|
||||
4. **Onvoldoende / Onze aanbeveling:** De audit is niet behaald.
|
||||
|
||||
### Wie beslist en wanneer ben ik gecertificeerd?
|
||||
Het is essentieel om te begrijpen dat de auditor alléén een aanbeveling doet [49, 50]. De definitieve beslissing ligt bij de certificatie-instelling (de Certification Body) die het volledige auditrapport onafhankelijk beoordeelt [50, 51].
|
||||
|
||||
Zodra de certificatie-instelling akkoord is, word je officieel gecertificeerd. Als er correctieplannen nodig waren, krijg je je certificaat pas nadat deze plannen zijn ingediend en goedgekeurd [47, 52].
|
||||
|
||||
### Geldigheid van het ISO 27001 certificaat
|
||||
Je behaalde certificaat is **drie jaar geldig** [51, 53]. Dat betekent echter niet dat je daarna drie jaar achterover kunt leunen. Het succes van ISO 27001 is continue verbetering. Daarom komt de auditor ieder jaar terug voor een kleinere *surveillance audit* om te controleren of het management systeem nog steeds effectief wordt onderhouden [51, 54]. In het derde jaar vindt de grotere hercertificeringsaudit plaats [53, 55].
|
||||
|
||||
56
marketing/publications/eBook-Audit/Angsten over de audit.md
Normal file
56
marketing/publications/eBook-Audit/Angsten over de audit.md
Normal file
|
|
@ -0,0 +1,56 @@
|
|||
# Angsten over de audit
|
||||
|
||||
Bij mensen en organisaties leven vooral dezelfde drie dingen rond een ISO 27001-audit: **angst om bewijs te missen**, onzekerheid over wat auditors precies verwachten, en onduidelijkheid over de grens tussen “een werkende securitypraktijk” en “auditwaardig bewijs”. In communities rond startups en security komt vooral naar voren dat veel teams wel controles hebben, maar die niet goed genoeg kunnen aantonen of documenteren.[1][2][3]
|
||||
|
||||
## Wat mensen bang maakt
|
||||
|
||||
De grootste angst is niet altijd “falen op inhoud”, maar falen op **bewijsvoering**: policies, logs, risk assessments, access reviews, vulnerability management en SOA-mapping moeten aantoonbaar op orde zijn. In Reddit-discussies zie je expliciet zorgen over auditfindings door ontbrekende records, inconsistent patchen en controles die wel bestaan maar niet organisatiebreed of aantoonbaar zijn ingevoerd. Bij founders leeft daarnaast de vrees dat een audit veel tijd en geld kost en deals vertraagt, vooral als enterprise-klanten de certificering als harde voorwaarde stellen.[4][5][6][7][8][9][1]
|
||||
|
||||
## Waar de onzekerheid zit
|
||||
|
||||
Veel onduidelijkheid gaat over **hoe streng auditors zijn** en wat er precies in fase 1 versus fase 2 kan misgaan. In de besproken bronnen wordt vaak benadrukt dat fase 1 al pijn kan doen als de managementsystematiek of documentatie niet klopt, terwijl fase 2 vooral gaat om werking en effectiviteit van de controles. Een terugkerende onzekerheid is ook of “goed genoeg voor security” hetzelfde is als “goed genoeg voor ISO 27001”; de discussies laten zien dat organisaties soms verrast zijn dat de standaard meer vraagt dan losse tools of losse beleidsdocumenten.[2][10][1]
|
||||
|
||||
## Grijze zones
|
||||
|
||||
Een ander thema is de **interpretatie van de norm**. Teams twijfelen bijvoorbeeld over vulnerability-managementtermijnen, scope-afbakening, risicoacceptatie, en hoeveel detail auditors willen zien in bewijsstukken en rationale. Ook wordt regelmatig genoemd dat leveranciers, compliance-platforms en consultants veel beloven, maar dat organisaties alsnog zelf de PDCA-cyclus, risico’s en justifications moeten dragen. Dat voedt het gevoel dat je pas tijdens de audit ontdekt wat er echt ontbreekt.[3][5][6][7][10]
|
||||
|
||||
## Wat in de praktijk terugkomt
|
||||
|
||||
De meest genoemde auditproblemen zijn vrij consistent: onvolledige risk assessments, zwakke access controls, ontbrekende of niet-getoetste incident response, onvoldoende training, lacunes in asset-inventarisatie en slechte supplier management-bewijsvoering. Op Reddit duikt ook vaak de zorg op dat een organisatie “de controls heeft”, maar dat de auditor vooral wil zien dat ze structureel, herhaalbaar en gedocumenteerd werken. Dat verklaart waarom mensen zo vaak spreken over “paperwork”, “evidence” en “audit trail” als de echte stressfactoren.[6][1][2][3][4]
|
||||
|
||||
## Specifiek voor kleine teams
|
||||
|
||||
Voor indie builders en kleine SaaS-teams gaat de angst vaak minder over technische onbekwaamheid en meer over **resource-tekort**: te weinig tijd, te weinig mensen en te weinig volwassen procesdiscipline. Daardoor voelt ISO 27001 soms als iets dat je pas kunt doen zodra je al groter bent, terwijl enterprise-sales juist vraagt om die certificering vóórdat je groot bent. Dat spanningsveld maakt de audit in de praktijk vaak emotioneler en strategischer dan puur technisch.[7][8][11]
|
||||
|
||||
Ik kan dit ook omzetten in een compacte lijst met: 1) angsten, 2) onzekerheden, 3) auditvragen, en 4) risico’s per doelgroep zoals founders, IT-teams en compliance leads.
|
||||
|
||||
Sources
|
||||
[1] ISO 27001 audit: is the hardest part already done, or can you still fail ... https://www.reddit.com/r/cybersecurity/comments/1q6pcnv/iso_27001_audit_is_the_hardest_part_already_done/
|
||||
[2] What We Learned from Our ISO 27001 Audit (Automation Isn't Everything) https://www.reddit.com/r/SaaS/comments/1msx6ts/what_we_learned_from_our_iso_27001_audit/
|
||||
[3] We built a GRC tool after watching SMBs fail ISO audits for ... https://news.ycombinator.com/item?id=47395503
|
||||
[4] ISO 27001 Common Audit Findings: A Practical Guide (2026) https://www.konfirmity.com/blog/iso-27001-common-audit-findings
|
||||
[5] Vulnerability management for ISO 27001, how do you keep up? https://www.reddit.com/r/cybersecurity/comments/1kvp3v1/vulnerability_management_for_iso_27001_how_do_you/
|
||||
[6] 10 most common non-conformities in ISO 27001 audits - Cyberday.ai https://www.cyberday.ai/blog/10-most-common-non-conformities-in-iso-27001-audits
|
||||
[7] I'm building a tool to make ISO 27001 accessible for ... https://www.reddit.com/r/TheFounders/comments/1rdiudz/im_building_a_tool_to_make_iso_27001_accessible/
|
||||
[8] Ask HN: Is the ISO 27001 certification worth it? https://news.ycombinator.com/item?id=29094889
|
||||
[9] the rule with these kinds of certifications is simple: don't do ... https://news.ycombinator.com/item?id=29099232
|
||||
[10] I'm building a tool to make ISO 27001 accessible for ... https://www.reddit.com/r/ISO27001/comments/1rdibs0/im_building_a_tool_to_make_iso_27001_accessible/
|
||||
[11] SOC 2 vs ISO 27001: what enterprise customers are ... https://www.reddit.com/r/soc2/comments/1s97onb/soc_2_vs_iso_27001_what_enterprise_customers_are/
|
||||
[12] 🚀 Building a Pre-Audit Tool for ISO 27001 Readiness https://www.reddit.com/r/cybersecurity/comments/1oe5a3k/building_a_preaudit_tool_for_iso_27001_readiness/
|
||||
[13] Bad Auditors... Be Warned https://www.reddit.com/r/ISO27001/comments/1l8q38p/bad_auditors_be_warned/
|
||||
[14] The 100 Most Common ISO 27001 Audit Failures (And ... https://www.gsdcouncil.org/blogs/the-100-most-common-iso-27001-audit-failures-and-how-to-fix-them
|
||||
[15] ISO 27001 Audit with a Self-Hosted Dashboard – Here’s the Behind-the-Scenes https://www.reddit.com/r/devops/comments/1ln990i/iso_27001_audit_with_a_selfhosted_dashboard_heres/
|
||||
[16] For CTOs and Technical Leaders - alphalist.CTO Podcast https://alphalist.podigee.io/feed/mp3
|
||||
[17] Agreed. As an ISO 27001 auditor I see a growing demand ... https://news.ycombinator.com/item?id=42114838
|
||||
[18] I'm building a tool to make ISO 27001 accessible for ... https://www.reddit.com/r/founder/comments/1rd6nbs/im_building_a_tool_to_make_iso_27001_accessible/
|
||||
[19] Well, yes, but that's the point of many contracts, they are ... https://news.ycombinator.com/item?id=47465044
|
||||
[20] Supabase - $7200/year for SOC2 (making it costly for many startups ... https://www.reddit.com/r/Supabase/comments/1j1isij/supabase_7200year_for_soc2_making_it_costly_for/
|
||||
[21] Sign up - Indie Apps https://indieapps.space/auth/sign_up
|
||||
[22] Indie Apps: Explore https://indieapps.space
|
||||
[23] Login to indieapps.space https://indieapps.space/auth/sign_in
|
||||
[24] What is Software? Definition, Types, Uses, and Benefits https://www.theknowledgeacademy.com/blog/what-is-software/
|
||||
[25] Dossier (@dossier@indieapps.space) - Explore - Indie Apps https://indieapps.space/@dossier
|
||||
[26] Callum M. - Software Engineering Manager at Wing | LinkedIn https://www.linkedin.com/in/callum-may
|
||||
[27] Android App Analytics Explained by Pros: 5 Lifehacks & Tools https://appfollow.io/blog/android-app-analytics
|
||||
[28] App icon design tips and best practices - AppTweak https://www.apptweak.com/en/aso-blog/how-to-design-an-app-icon
|
||||
[29] Games (@games@indieapps.space) - Indie Apps https://indieapps.space/@games
|
||||
16
marketing/publications/eBook-Audit/Hoe bereid je je voor.md
Normal file
16
marketing/publications/eBook-Audit/Hoe bereid je je voor.md
Normal file
|
|
@ -0,0 +1,16 @@
|
|||
# Hoe bereid je je voor op de Fase 2 audit?
|
||||
|
||||
Rolhouders krijgen ruim de tijd om zich voor te bereiden, doordat de auditor vooraf een auditplan deelt waarin specifieke rollen of expertises op bepaalde tijdstippen worden ingepland. Om goed beslagen ten ijs te komen tijdens het interview, kunnen de betreffende personen zich op de volgende manieren voorbereiden:
|
||||
|
||||
- **Begrijp dat het geen functioneringsgesprek is:** Een auditor beoordeelt niet de persoonlijke prestaties van de werknemer, maar wil simpelweg begrijpen hoe de processen in de organisatie werken. Er zijn geen "goede" of "foute" antwoorden, dus rolhouders hoeven niet nerveus te zijn.
|
||||
- **Wees voorbereid om je rol toe te lichten:** De auditor zal het gesprek vaak beginnen met de vraag om kort je rol en achtergrond te beschrijven, om er zeker van te zijn dat hij of zij de juiste materiedeskundige tegenover zich heeft.
|
||||
- **Zorg dat je bewijs bij de hand hebt ('Show, don't tell'):** Mondelinge antwoorden worden door auditors beschouwd als de minst betrouwbare vorm van bewijs. Bereid je erop voor dat de auditor je vraagt om je uitleg direct aan te tonen, bijvoorbeeld door het tonen van systeemconfiguraties, logbestanden, of door een proces live te demonstreren (technische verificatie).
|
||||
- **Geef specifieke antwoorden over de dagelijkse praktijk:** Auditors stellen open vragen zoals "leg uit" of "laat zien". Vertel de auditor niet wat je _zou moeten_ doen in theorie, maar leg heel specifiek uit wat je _daadwerkelijk doet_ in de dagelijkse praktijk met betrekking tot de systemen of processen die binnen de audit-scope vallen.
|
||||
- **Weet waar documentatie staat:** Zelfs als je een document niet zelf hebt geschreven, wil een auditor toetsen of de communicatie in de organisatie effectief is. De auditor kan bijvoorbeeld vragen of je op de hoogte bent van een nieuw beleid en of je kunt laten zien waar je dit op het bedrijfsintranet kunt vinden.
|
||||
- **Laat de gids (guide) niet voor je praten:** Als er een gids (begeleider) vanuit de organisatie bij het interview aanwezig is, zal de auditor verwachten dat jij als materiedeskundige zélf antwoord geeft. De gids is er alleen ter facilitering en mag het proces niet beïnvloeden of vragen voor jou beantwoorden.
|
||||
|
||||
**Specifieke voorbereiding voor het Topmanagement (de directie):** Wanneer de auditor in gesprek gaat met de directie, hoeven zij zich niet voor te bereiden op technische vragen of jargon. Zij moeten zich voorbereiden op strategische vragen door na te denken over:
|
||||
|
||||
- Hoe het Information Security Management System (ISMS) hen helpt om de algemene bedrijfsdoelstellingen te behalen.
|
||||
- Op welke manier zij als directie betrokken zijn, bijvoorbeeld door het beschikbaar stellen van budget, tijd en middelen.
|
||||
- Hoe zij zelf de zekerheid (assurance) krijgen dat de juiste processen en beveiligingsmaatregelen effectief werken, bijvoorbeeld via rapportages of management reviews.
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
# Hoe 'technisch' is de audit?
|
||||
|
||||
*In de PECB training worden vaak technische security experts genoemd, bijv. 'de firewall-engineer'. In hoeverre moet de auditor inhoudelijk technische kennis hebben? Moet hij bijv. een oordeel hebben over de configuratie van de firewall?*
|
||||
|
||||
Hoewel je als individuele auditor niet verwacht wordt om elk technisch detail van elk mogelijk systeem of framework te kennen, is inhoudelijke technische kennis wel degelijk vereist om een succesvolle ISO 27001-audit uit te voeren.
|
||||
|
||||
Hier is hoe de norm en de praktijk hiermee omgaan:
|
||||
|
||||
**1. Collectieve kennis en het gebruik van Technische Experts** De norm eist dat het auditteam _collectief_ (als geheel) over de benodigde kennis van IT-tools, methoden en de implementatie van de Annex A-maatregelen beschikt. Een goede auditor moet de onderliggende technologie begrijpen, anders is het onmogelijk om met redelijke zekerheid vast te stellen of technische maatregelen goed zijn geïmplementeerd. Echter, als jij als auditor de specifieke diepgaande kennis mist (bijvoorbeeld op het gebied van database-configuraties, softwareontwikkeling of complexe netwerken), dan mag (en moet) je een 'technical expert' (technisch expert) aan het auditteam toevoegen om die inhoudelijke beoordeling voor jou te doen.
|
||||
|
||||
**2. Beoordeling van de firewall (Technical Verification)** Wat betreft de firewall: **ja, er wordt absoluut verwacht dat je (of jouw ingeschakelde technisch expert) de effectiviteit van de configuratie inhoudelijk kan beoordelen**. Dit valt onder de auditprocedure _technical verification_. Mondelinge bevestiging is immers onvoldoende bewijs. Als de firewall-engineer jou vertelt dat zij specifiek netwerkverkeer aan de rand van het netwerk filteren, dan zul je de configuratie van die firewall (zoals de Access Control Lists of VPN-instellingen) moeten inzien. Je analyseert dan de regelsets om te zoeken naar mogelijke gaten, misconfiguraties of verkeer dat ten onrechte wordt doorgelaten.
|
||||
|
||||
**3. De harde grens: Geen "hands-on" acties door de auditor** Er is bij deze technische verificatie één keiharde regel: **een auditor mag nooit zelf 'hands-on' testen of systemen bedienen**. Zelfs als jij zelf een voormalig netwerkengineer bent en exact weet hoe de interface van een specifieke firewall werkt, mag je vanwege aansprakelijkheidsrisico's (liability risks) en onafhankelijkheid nooit zélf de muis overnemen, commando's intypen of zelfstandig kwetsbaarheidsscans (zoals Nessus) draaien op het netwerk van de klant.
|
||||
|
||||
De werkwijze is in plaats daarvan altijd dat je de technische beheerder (in dit geval de firewall-engineer) vraagt om in te loggen, de configuraties of rapportages op het scherm te openen en deze aan jou te _demonstreren_ of uit te leggen, terwijl jij meekijkt en het inhoudelijk beoordeelt.
|
||||
BIN
marketing/publications/eBook-Audit/ISO27DIY-ebook.pdf
Normal file
BIN
marketing/publications/eBook-Audit/ISO27DIY-ebook.pdf
Normal file
Binary file not shown.
|
|
@ -0,0 +1,28 @@
|
|||
# Wie moeten er aanwezig zijn?
|
||||
|
||||
*Wie moeten er tijdens de audit beschikbaar zijn om vragen over documentatie van de auditor te beantwoorden?*
|
||||
|
||||
Tijdens een ISO 27001-audit is er niet slechts één centrale "documentatie-eigenaar" die alle vragen over de documentatie hoeft te beantwoorden. De norm hanteert voor "gedocumenteerde informatie" (wat onder de bredere definitie van bedrijfsmiddelen of _assets_ valt) een gedecentraliseerde aanpak. Dit betekent dat het eigenaarschap en de verantwoordelijkheid afhankelijk zijn van het soort document.
|
||||
|
||||
Omdat de norm vereist dat alle informatie een specifieke **eigenaar** krijgt toegewezen, zal de auditor zijn vragen primair richten aan de aangewezen eigenaar of verantwoordelijke van het specifieke document. Om de vragen van de auditor adequaat te beantwoorden, moeten afhankelijk van het document de volgende personen beschikbaar zijn:
|
||||
|
||||
- **Het Topmanagement (de directie):** Voor het overkoepelende Informatiebeveiligingsbeleid (het document op het hoogste niveau) ligt de verantwoordelijkheid voor de vaststelling en goedkeuring uitsluitend bij de directie. De auditor zal direct met het topmanagement in gesprek willen gaan om dit beleid te bespreken.
|
||||
- **Systeemeigenaren, Security Officers of Afdelingsmanagers:** Voor onderwerpspecifieke beleidsregels (zoals regels rondom toegangsbeveiliging of cryptografie) ligt de verantwoordelijkheid bij personeel met het juiste bevoegdheidsniveau en de benodigde technische bekwaamheid. Deze materiedeskundigen moeten beschikbaar zijn om in detail uit te leggen hoe deze beleidsregels zijn ontwikkeld en goedgekeurd.
|
||||
- **Uitvoerend personeel (zoals technici of beheerders):** Bij werkinstructies en gedocumenteerde bedieningsprocedures eist de norm dat in het document zélf expliciet staat welke personen verantwoordelijk zijn voor de beschreven handelingen. De auditor zal deze personen willen interviewen om na te gaan of de documentatie in de praktijk ook echt wordt gevolgd.
|
||||
- **De formele beoordelaars en auteurs:** Voor élk stuk gedocumenteerde informatie vereist ISO 27001 een proces van formele beoordeling en goedkeuring door iemand met de juiste autoriteit, evenals de identificatie van de auteur. Deze personen kunnen door de auditor worden aangesproken over de toereikendheid en geschiktheid van de inhoud.
|
||||
- **Verantwoordelijken voor registraties (artifacts):** Registraties zoals logbestanden of auditrapporten vormen het feitelijke bewijs dat een proces is uitgevoerd. De specifieke actoren (zoals een eigenaar of beheerder) die aan deze registraties gekoppeld zijn, moeten beschikbaar zijn om deze bewijsstukken aan te leveren en eventueel toe te lichten.
|
||||
- **Beheerders van het documentatiesysteem:** De auditor zal mogelijk ook vragen stellen aan de personen die verantwoordelijk zijn voor het beheer, de archivering en het up-to-date houden van de documentatie. Zij moeten kunnen aantonen hoe documenten worden gedistribueerd en afgeschermd tegen ongeautoriseerde aanpassingen.
|
||||
|
||||
Kortom, de auditor zal altijd op zoek gaan naar de specifieke experts en eigenaren binnen de organisatie. Zorg er daarom voor dat bij de voorbereiding van de audit per document of proces helder is wie de toegewezen eigenaar is, zodat de juiste persoon aan tafel zit om de vragen van het auditteam te beantwoorden.
|
||||
|
||||
## Geeft de auditor voorafgaand aan Stage 2 aan wie hij wil spreken?
|
||||
|
||||
**Ja, absoluut.** Voorafgaand aan de Stage 2 audit stelt de auditor (specifiek de lead auditor) een gedetailleerd **auditplan** of **auditschema** op, dat ruim van tevoren – vaak al rond de 6 weken voor de start van de audit – met jouw organisatie wordt gedeeld.
|
||||
|
||||
In dit schema staat precies aangegeven op welk tijdstip de auditor welke systemen, processen of specifieke controles wil doorlichten. Wat betreft de te spreken personen werkt dit als volgt:
|
||||
|
||||
- **Rollen en expertises in plaats van namen:** Omdat de auditor logischerwijs niet de exacte namen van al jouw medewerkers kent, zal hij of zij in het auditplan vragen om specifieke **rollen of materiedeskundigen (subject matter experts)**. De auditor geeft bijvoorbeeld in de planning aan: _"In dit tijdslot moet ik spreken met de firewall-engineer"_, _"Ik wil spreken met de security architect"_ of _"Ik wil iemand spreken over het patchmanagement-proces"_.
|
||||
- **De organisatie vult de namen in:** Het is vervolgens aan jouw organisatie om de juiste medewerkers aan deze specifieke tijdsloten te koppelen en aan de auditor te bevestigen wie deze personen zijn.
|
||||
- **Voorbereiding:** Doordat dit ruim van tevoren in het auditplan wordt vastgelegd, weet iedereen binnen de organisatie al ruim voor de audit begint precies wanneer ze verwacht worden voor een interview met de auditor. Dit stelt jouw organisatie ook in staat om er voor te zorgen dat de juiste mensen beschikbaar zijn of dat er eventueel vervanging wordt geregeld als iemand op vakantie is.
|
||||
|
||||
Mocht tijdens de audit overigens blijken dat de persoon die tegenover de auditor zit niet de juiste kennis heeft om de vragen te beantwoorden, dan zal de auditor vragen om dit aan te passen en alsnog de juiste deskundige voor dat specifieke proces te spreken.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 134 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 115 KiB |
57
marketing/publications/eBook-Audit/build.sh
Executable file
57
marketing/publications/eBook-Audit/build.sh
Executable file
|
|
@ -0,0 +1,57 @@
|
|||
#!/bin/bash
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
# ISO27DIY eBook build script
|
||||
# Run from: my-vault/iso27DIY-mkII/marketing/eBook-Audit/
|
||||
# cd path/to/my-vault/iso27DIY-mkII/marketing/eBook-Audit && bash build.sh
|
||||
# ─────────────────────────────────────────────────────────────
|
||||
|
||||
set -e
|
||||
|
||||
# ── CONFIG ────────────────────────────────────────────────────
|
||||
SOURCE="ebook-iso27001-audit.md" # Your Markdown source file
|
||||
OUTPUT="ISO27DIY-ebook.pdf" # Output PDF name
|
||||
TEMPLATE="iso27diy-book.tex" # LaTeX template
|
||||
|
||||
# ── COLORS FOR OUTPUT ─────────────────────────────────────────
|
||||
RED='\033[0;31m'
|
||||
GREEN='\033[0;32m'
|
||||
BLUE='\033[0;34m'
|
||||
NC='\033[0m' # No Color
|
||||
|
||||
echo -e "${BLUE}Building ISO27DIY eBook...${NC}"
|
||||
echo " Source: $SOURCE"
|
||||
echo " Output: $OUTPUT"
|
||||
echo ""
|
||||
|
||||
# ── CHECK DEPENDENCIES ────────────────────────────────────────
|
||||
command -v pandoc >/dev/null 2>&1 || {
|
||||
echo -e "${RED}Error: pandoc not found. Run: brew install pandoc${NC}"
|
||||
exit 1
|
||||
}
|
||||
command -v xelatex >/dev/null 2>&1 || {
|
||||
echo -e "${RED}Error: xelatex not found. Run: brew install --cask mactex${NC}"
|
||||
exit 1
|
||||
}
|
||||
|
||||
# ── BUILD ─────────────────────────────────────────────────────
|
||||
pandoc "$SOURCE" \
|
||||
--template="$TEMPLATE" \
|
||||
--pdf-engine=xelatex \
|
||||
--pdf-engine-opt=-shell-escape \
|
||||
--toc \
|
||||
--toc-depth=2 \
|
||||
--syntax-highlighting=tango \
|
||||
--from=markdown+smart+footnotes+definition_lists \
|
||||
-V documentclass=report \
|
||||
--output="$OUTPUT"
|
||||
|
||||
# ── DONE ──────────────────────────────────────────────────────
|
||||
if [ -f "$OUTPUT" ]; then
|
||||
SIZE=$(du -sh "$OUTPUT" | cut -f1)
|
||||
echo -e "${GREEN}Done! → $OUTPUT ($SIZE)${NC}"
|
||||
# Open the PDF automatically
|
||||
open "$OUTPUT"
|
||||
else
|
||||
echo -e "${RED}Build failed. Check the output above for errors.${NC}"
|
||||
exit 1
|
||||
fi
|
||||
111
marketing/publications/eBook-Audit/eBook download triggers.md
Normal file
111
marketing/publications/eBook-Audit/eBook download triggers.md
Normal file
|
|
@ -0,0 +1,111 @@
|
|||
# Triggers
|
||||
## LinkedIn post (langere variant)
|
||||
|
||||
**De meeste ISO 27001-audits mislukken niet op security. Ze mislukken op bewijs.**
|
||||
|
||||
Je hebt de controls. Je patcht. Je hebt een beleid voor toegangsbeheer. Je doet aan logging.
|
||||
|
||||
Maar als de auditor vraagt: _"Laat eens zien"_ — dan begint het zweten.
|
||||
|
||||
Ontbrekende logs. Een risk assessment dat nooit echt is bijgehouden. Een incident response plan dat niemand heeft getest. Een SOA die niet klopt met wat je daadwerkelijk doet.
|
||||
|
||||
Dat is het echte probleem met ISO 27001-audits: je ontdekt de gaten pas als het te laat is.
|
||||
|
||||
Ik heb een eBook geschreven voor iedereen die een audit in het vizier heeft en wil weten wat er écht bij komt kijken — zonder consultantentaal, zonder gladde beloftes.
|
||||
|
||||
**Wat je leert:**
|
||||
|
||||
- Wat auditors in fase 1 en fase 2 anders beoordelen
|
||||
- Welke non-conformities het vaakst opduiken (en waarom)
|
||||
- Hoe je bewijsvoering organiseert vóórdat je voor verrassingen staat
|
||||
|
||||
Gratis te downloaden. Link in de reacties.
|
||||
|
||||
## Kortere post (LinkedIn / andere kanalen)
|
||||
|
||||
**ISO 27001-audit: het zit hem niet in de controls. Het zit hem in het bewijs.**
|
||||
|
||||
Veel teams hebben de security op orde. Wat ze niet hebben: een sluitend audittrail. Gedocumenteerde risk assessments. Aantoonbare access reviews. Een SOA die klopt.
|
||||
|
||||
Pas tijdens de audit merk je wat er ontbreekt.
|
||||
|
||||
In mijn gratis eBook leg ik uit hoe een audit écht werkt — fase 1, fase 2, wat auditors zoeken, wat het vaakst misgaat. Zonder omwegen.
|
||||
|
||||
🔗 [link]
|
||||
|
||||
## Ultrakorte versie (X / nieuwsbrief snippet)
|
||||
|
||||
**Weet je wat auditors zoeken? Niet of je security werkt. Of je kunt bewijzen dat het werkt.**
|
||||
|
||||
Dat onderscheid kost organisaties elk jaar certificeringen.
|
||||
|
||||
Gratis eBook: alles wat je wilt weten over de ISO 27001-audit → [link]
|
||||
|
||||
## Nieuwsbrief intro (voor bestaande lijst)
|
||||
|
||||
Veel mensen die zich voorbereiden op een ISO 27001-audit denken dat ze er klaar voor zijn. Ze hebben beleid, tools, processen.
|
||||
|
||||
En dan begint de audit.
|
||||
|
||||
De auditor vraagt om een risk assessment. Je hebt er eentje — maar het is 14 maanden oud en nooit bijgewerkt. Hij vraagt om bewijs van een access review. Dat is gedaan, maar niemand heeft het vastgelegd. Hij vraagt naar supplier management. Stilte.
|
||||
|
||||
Niet omdat de organisatie slecht bezig was. Maar omdat er een verschil zit tussen _security die werkt_ en _security die aantoonbaar werkt_.
|
||||
|
||||
Dat verschil leg ik uit in mijn nieuwe eBook. Gratis, direct beschikbaar na inschrijving.
|
||||
|
||||
## Landingspagina voor download
|
||||
|
||||
|
||||
**De ISO 27001 audit: wat je écht moet weten** _Gratis eBook — direct in je inbox_
|
||||
|
||||
---
|
||||
|
||||
Je audit komt eraan. Of je overweegt hem serieus.
|
||||
|
||||
Je hebt een beveiligingsbeleid. Je patcht. Je hebt toegangsbeheer geregeld. En toch zit er ergens een ongemakkelijk gevoel: _ben ik écht klaar?_
|
||||
|
||||
Dat gevoel klopt. De meeste organisaties die struikelen bij een ISO 27001-audit, doen dat niet omdat hun security slecht is. Ze struikelen omdat ze niet kunnen aantonen dat het werkt.
|
||||
|
||||
Ontbrekende records. Een risicoanalyse die niemand heeft bijgehouden. Een Statement of Applicability die niet meer klopt met de praktijk. Een incident response plan dat ooit is geschreven maar nooit getest.
|
||||
|
||||
Dat ontdek je normaal gesproken tijdens de audit. Dit eBook zorgt dat je het daarvoor weet.
|
||||
|
||||
---
|
||||
|
||||
**Wat je leest:**
|
||||
|
||||
- Hoe Stage 1 en Stage 2 van elkaar verschillen — en waarom Stage 1 al pijn kan doen
|
||||
- Wat auditors zoeken als ze zeggen "laat het me zien"
|
||||
- Welke non-conformiteiten het vaakst opduiken, en wat ze gemeen hebben
|
||||
- Hoe je bewijsvoering organiseert vóórdat de auditor binnenkomt
|
||||
- Wat een Corrective Action Plan moet bevatten — en wanneer je er een nodig hebt
|
||||
- Wat het certificaat waard is, hoe lang het geldig is, en wat daarna komt
|
||||
|
||||
---
|
||||
|
||||
_Vul je e-mailadres in. Je ontvangt het eBook direct._
|
||||
|
||||
[ e-mailadres ]
|
||||
|
||||
**[ Ik wil weten wat auditors zoeken ]**
|
||||
|
||||
_Geen spam. Af en toe een mail als er iets de moeite waard is._
|
||||
|
||||
---
|
||||
|
||||
## Toelichting op de keuzes
|
||||
|
||||
**Openingszin** slaat geen alarm, maar benoemt de situatie feitelijk. Iedereen die op deze pagina landt, herkent zich daarin.
|
||||
|
||||
**"Dat gevoel klopt"** — bevestigt de angst zonder er in te drammen. Daarna volgt direct de verklaring: het probleem is bewijsvoering, niet security.
|
||||
|
||||
**De bulletlijst** is functioneel, geen marketingproza. Elk punt benoemt iets concreets uit het eBook — geen vage beloftes.
|
||||
|
||||
**CTA-knoptekst: "Ik wil weten wat auditors zoeken"** — eerste persoon, actief, sluit aan op de kernangst. Alternatieven als je wilt testen:
|
||||
|
||||
|Variant|Wanneer|
|
||||
|---|---|
|
||||
|Ik wil weten wat auditors zoeken|Voorkeur — sluit aan op de angst|
|
||||
|Stuur me het eBook|Functioneel, geen wrijving|
|
||||
|Ik ben klaar voor de audit|Aspirationeel, licht eigenzinnig|
|
||||
|
||||
|
|
@ -0,0 +1,78 @@
|
|||
<style>
|
||||
.wrap { display: flex; flex-direction: column; gap: 24px; padding: 1rem 0; }
|
||||
.label { font-size: 11px; font-weight: 500; color: var(--color-text-secondary); text-transform: uppercase; letter-spacing: 0.08em; margin-bottom: 8px; }
|
||||
.spread { display: grid; grid-template-columns: 1fr 1fr; gap: 16px; }
|
||||
.page { border: 0.5px solid var(--color-border-secondary); border-radius: 4px; overflow: hidden; }
|
||||
</style>
|
||||
|
||||
<div class="wrap">
|
||||
|
||||
<div>
|
||||
<div class="label">Cover — dark navy with red + blue brand</div>
|
||||
<div class="spread">
|
||||
<div class="page">
|
||||
<svg viewBox="0 0 280 360" xmlns="http://www.w3.org/2000/svg">
|
||||
<rect width="280" height="360" fill="#1a2535"/>
|
||||
<rect x="0" y="0" width="5" height="360" fill="#b31c1c"/>
|
||||
<image href="/mnt/user-data/uploads/ISO27DIY_LOGO_rgb_white.jpg" x="20" y="22" width="52" height="52"/>
|
||||
<text x="24" y="136" font-family="system-ui,sans-serif" font-size="30" fill="white" font-weight="700">ISO 27001</text>
|
||||
<text x="24" y="166" font-family="system-ui,sans-serif" font-size="30" fill="white" font-weight="700">Certification</text>
|
||||
<text x="24" y="196" font-family="system-ui,sans-serif" font-size="30" fill="white" font-weight="700">Guide</text>
|
||||
<rect x="24" y="210" width="56" height="3" fill="#2d8fd4"/>
|
||||
<text x="24" y="234" font-family="system-ui,sans-serif" font-size="11" fill="#8ba0b8">A practical roadmap for small</text>
|
||||
<text x="24" y="250" font-family="system-ui,sans-serif" font-size="11" fill="#8ba0b8">and mid-sized companies</text>
|
||||
<text x="24" y="338" font-family="system-ui,sans-serif" font-size="9" fill="#4a6070">iso27diy.com</text>
|
||||
</svg>
|
||||
</div>
|
||||
<div class="page">
|
||||
<svg viewBox="0 0 280 360" xmlns="http://www.w3.org/2000/svg">
|
||||
<rect width="280" height="360" fill="#ffffff"/>
|
||||
<rect x="0" y="0" width="280" height="36" fill="#1a2535"/>
|
||||
<text x="16" y="22" font-family="system-ui,sans-serif" font-size="8.5" fill="#8ba0b8">ISO 27001 Certification Guide</text>
|
||||
<text x="264" y="22" font-family="system-ui,sans-serif" font-size="8.5" fill="#2d8fd4" text-anchor="end">12</text>
|
||||
<text x="20" y="66" font-family="system-ui,sans-serif" font-size="8" fill="#b31c1c" letter-spacing="1.8" font-weight="700">STEP 3</text>
|
||||
<text x="16" y="90" font-family="system-ui,sans-serif" font-size="22" fill="#1a2535" font-weight="700">Assign</text>
|
||||
<text x="16" y="114" font-family="system-ui,sans-serif" font-size="22" fill="#1a2535" font-weight="700">Responsibilities</text>
|
||||
<rect x="16" y="122" width="248" height="0.5" fill="#dde3ea"/>
|
||||
<rect x="16" y="138" width="3" height="66" fill="#2d8fd4"/>
|
||||
<rect x="16" y="138" width="248" height="66" fill="#eef4fb"/>
|
||||
<text x="26" y="155" font-family="system-ui,sans-serif" font-size="8.5" fill="#185fa5" font-weight="700">Auditor will ask</text>
|
||||
<text x="26" y="169" font-family="system-ui,sans-serif" font-size="8.5" fill="#1a2535">Document who is responsible for</text>
|
||||
<text x="26" y="182" font-family="system-ui,sans-serif" font-size="8.5" fill="#1a2535">what. Capture this in a RASCI matrix</text>
|
||||
<text x="26" y="195" font-family="system-ui,sans-serif" font-size="8.5" fill="#1a2535">before the audit.</text>
|
||||
<text x="16" y="222" font-family="system-ui,sans-serif" font-size="8.5" fill="#333">A functioning ISMS requires clarity about</text>
|
||||
<text x="16" y="236" font-family="system-ui,sans-serif" font-size="8.5" fill="#333">who is responsible for what, and who</text>
|
||||
<text x="16" y="250" font-family="system-ui,sans-serif" font-size="8.5" fill="#333">makes which decisions. ISO 27001 names</text>
|
||||
<text x="16" y="264" font-family="system-ui,sans-serif" font-size="8.5" fill="#333">three roles explicitly.</text>
|
||||
<rect x="16" y="278" width="248" height="0.5" fill="#dde3ea"/>
|
||||
<rect x="16" y="288" width="4" height="4" rx="1" fill="#b31c1c"/>
|
||||
<text x="26" y="294" font-family="system-ui,sans-serif" font-size="8.5" fill="#1a2535" font-weight="600">Top management</text>
|
||||
<text x="26" y="306" font-family="system-ui,sans-serif" font-size="8.5" fill="#555">Responsible for policy. Liability cannot be delegated.</text>
|
||||
<rect x="16" y="316" width="4" height="4" rx="1" fill="#b31c1c"/>
|
||||
<text x="26" y="322" font-family="system-ui,sans-serif" font-size="8.5" fill="#1a2535" font-weight="600">Risk owners</text>
|
||||
<text x="26" y="334" font-family="system-ui,sans-serif" font-size="8.5" fill="#555">Business managers whose objectives are at stake.</text>
|
||||
<text x="140" y="352" font-family="system-ui,sans-serif" font-size="9" fill="#2d8fd4" text-anchor="middle">· · ·</text>
|
||||
</svg>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
<div>
|
||||
<div class="label">Chapter opener page</div>
|
||||
<div style="max-width: 50%; padding-right: 8px;">
|
||||
<div class="page">
|
||||
<svg viewBox="0 0 280 360" xmlns="http://www.w3.org/2000/svg">
|
||||
<rect width="280" height="360" fill="#1a2535"/>
|
||||
<text x="24" y="80" font-family="system-ui,sans-serif" font-size="9" fill="#2d8fd4" letter-spacing="2" font-weight="600">CHAPTER 2</text>
|
||||
<text x="24" y="120" font-family="system-ui,sans-serif" font-size="26" fill="white" font-weight="700">Risk</text>
|
||||
<text x="24" y="150" font-family="system-ui,sans-serif" font-size="26" fill="white" font-weight="700">Management</text>
|
||||
<rect x="24" y="166" width="44" height="3" fill="#b31c1c"/>
|
||||
<text x="24" y="194" font-family="system-ui,sans-serif" font-size="10" fill="#8ba0b8">Understanding your exposure</text>
|
||||
<text x="24" y="210" font-family="system-ui,sans-serif" font-size="10" fill="#8ba0b8">before you build controls.</text>
|
||||
<text x="24" y="344" font-family="system-ui,sans-serif" font-size="8" fill="#4a6070">iso27diy.com</text>
|
||||
</svg>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
|
@ -0,0 +1 @@
|
|||
ebook-design-reference.html
|
||||
302
marketing/publications/eBook-Audit/ebook-iso27001-audit.md
Normal file
302
marketing/publications/eBook-Audit/ebook-iso27001-audit.md
Normal file
|
|
@ -0,0 +1,302 @@
|
|||
---
|
||||
title: "De ISO 27001 audit"
|
||||
covertitle: "De ISO 27001 audit"
|
||||
subtitle: "Wat je écht moet weten – Een praktische gids"
|
||||
author: "Thinking Security Works"
|
||||
year: "Copyright 2026"
|
||||
logo: "assets/ISO27DIY_Logo_in_white_circle.png"
|
||||
toc: true
|
||||
index: false
|
||||
documentclass: book
|
||||
fontsize: 11pt
|
||||
papersize: a4
|
||||
lang: nl-NL
|
||||
pdf-engine: xelatex
|
||||
template: iso27diy-book.tex
|
||||
---
|
||||
|
||||
|
||||
|
||||
```{=latex}
|
||||
\begin{callout}{Voor wie is dit eBook?}
|
||||
Dit eBook is geschreven voor iedereen die een ISO 27001-certificering overweegt en wil begrijpen hoe het er in een audit écht aan toe gaat. Je leest waar auditors naar op zoek zijn, wat er vaak misgaat, en waarom de 93 maatregelen minder belangrijk zijn dan je denkt.
|
||||
\end{callout}
|
||||
\clearpage
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
## Waarom een ISO 27001-certificering?
|
||||
|
||||
ISO 27001 is de internationale standaard voor informatiebeveiliging. Een ISO 27001 certificaat bewijst dat je de beveiliging van informatie structureel managed via een Information Security Management System (ISMS). Dat betekent dat je processen hebt geïmplementeerd waarmee je continu de risico's bewaakt en passende maatregelen treft.
|
||||
|
||||
Organisaties kiezen voor ISO 27001 om verschillende redenen. Meestal één van de onderstaande, vaak een combinatie ervan:
|
||||
|
||||
**Inkoopvoorwaarden van klanten.** Met name grote klanten stellen ISO 27001 als harde voorwaarde. Aanvankelijk vooral in de publieke sector, financiële dienstverlening en zorg (NEN 7510), maar als gevolg van ketenverantwoordelijkheid in wet- en regelgeving wordt het steeds meer een 'license to sell'.
|
||||
|
||||
**Aanbestedingen.** In Europa is ISO 27001 (of gelijkwaardige aantoonbare informatiebeveiliging) een standaardeis in overheidstenders.
|
||||
|
||||
**Wet- en regelgeving**. Kaders als de NIS-2, de Cyberbeveiligingswet (Cbw), de Cyber Resilience Act (CRA), DORA en GDPR hebben een grootste gemene deler: robuuste informatiebeveiliging op basis van risicomanagement en een 'all risk approach'. Dit is precies wat je met een ISO 27001 certificering kunt aantonen.
|
||||
|
||||
**Vertrouwen richting klanten en partners.** Het certificaat zegt: wij houden ons verantwoordelijk voor de beveiliging van uw informatie, wij nemen dat serieus, en we laten dat onafhankelijk toetsen – dat is een sterker signaal dan de belofte je best te doen.
|
||||
|
||||
**Operationele volwassenheid.** Het certificeringstraject dwingt je om je eigen huis op orde te brengen: risico's te benoemen, verantwoordelijkheden vast te leggen, en processen herhaalbaar te maken. Je groeit als organisatie van incidentgedreven naar voortdurend verbeterend. Daarnaast zul je onbekende gaten in je beveiligingsproces ontdekken.
|
||||
|
||||
Organisaties die de certificering aanvaren als het afvinken van maatregelen en het produceren van overbodige documentatie missen de kern en merken dat tijdens de audit – ze komen meestal niet verder dan Fase I.
|
||||
|
||||
|
||||
|
||||
## Ben ik klaar voor de audit?
|
||||
|
||||
Dit is de vraag die begrijpelijker wijs de meeste stress oplevert. We kunnen deze vraag niet beantwoorden met een checklist.
|
||||
|
||||
Een organisatie is klaar voor de externe audit als ze het ISMS heeft ingericht, èn getoetst op effectieve werking. Meer concreet betekent het dat de volgende stappen moeten zijn afgerond voordat de auditor langskomt.
|
||||
|
||||
### Wat minimaal op orde moet zijn
|
||||
|
||||
**Het ISMS is operationeel.** De fundamentele processen uit de norm — hoofdstuk 4 tot en met 10 — draaien aantoonbaar. De scope is afgebakend, het informatiebeveiligingsbeleid is ondertekend, en er is een risicoanalyse uitgevoerd die is vertaald naar een risicobehandelplan.
|
||||
|
||||
**Er is een interne audit uitgevoerd.** Voordat de externe auditor komt, vereist de norm dat je het systeem zelf hebt geëvalueerd. Minimaal één interne audit, met een auditrapport als uitkomst. Eventuele afwijkingen zijn gedocumenteerd en worden opgevolgd.
|
||||
|
||||
**De directiebeoordeling heeft plaatsgevonden.** Na de interne audit beoordeelt het topmanagement formeel de prestaties en effectiviteit van het ISMS. Dit is geen formaliteit maar het bewijs dat de directie betrokken is.
|
||||
|
||||
**De verplichte documentatie is beschikbaar.** Denk aan de Verklaring van Toepasselijkheid (de Statement of Applicability of SoA), procedures, en de registraties van de interne audit en directiebeoordeling. Ze moeten bestaan, vindbaar zijn, en beheerd worden.
|
||||
|
||||
Kort samengevat: als je het ISMS hebt ingericht én je de Plan-Do-Check-Act cyclus minimaal één keer zelf hebt doorlopen, ben je klaar om een certificeringsinstantie te benaderen.
|
||||
|
||||
### Moet alles perfect zijn?
|
||||
|
||||
Nee. Een auditor verwacht niet dat elke maatregel op dag één 100% is doorgevoerd. Zolang het managementfundament draait, accepteert de norm dat je met een risicobehandelplan werkt. Als een maatregel later wordt geïmplementeerd en de directie het restrisico (voorlopig) formeel accepteert, is dat toegestaan.
|
||||
|
||||
Wees hier wel transparant over: claim niet dat iets is geïmplementeerd terwijl dat in feite nog (deels) moet gebeuren. Een goede auditor prikt hier snel doorheen en het geeft een slechte indruk voor de betrouwbaarheid van het ISMS.
|
||||
|
||||
|
||||
|
||||
## Hoe lang duurt een audit — en wat kost het?
|
||||
|
||||
Twee vragen die altijd samen worden gesteld, en waarop het antwoord altijd hetzelfde begint: *het hangt ervan af.* Maar we kunnen wel bandbreedtes geven.
|
||||
|
||||
### Het aantal dagen is genormeerd
|
||||
|
||||
Het aantal auditdagen is niet iets wat een certificeringsinstantie zelf mag verzinnen. Het is gereguleerd door de ISO 27006-norm, op basis van de grootte van de organisatie. Offertes van verschillende instanties zullen daarom vaak op een vergelijkbaar aantal dagen uitkomen.
|
||||
|
||||
Ruwe richtlijnen:
|
||||
|
||||
| Organisatiegrootte | Totaal auditdagen (basis) |
|
||||
| --- | --- |
|
||||
| 1–10 medewerkers | 5 dagen |
|
||||
| 11–15 medewerkers | 6 dagen |
|
||||
| 176–275 medewerkers | 14 dagen |
|
||||
|
||||
Een deel van die dagen zal de auditor bij jou op kantoor of in de fabriek aanwezig zijn.
|
||||
|
||||
Voor de minimale audit van 5 dagen ziet de tijdsverdeling er doorgaans zo uit:
|
||||
|
||||
- ½ dag: planning en voorbereiding
|
||||
- 1 dag: Fase 1 (documentatie-audit)
|
||||
- 3 dagen: Fase 2 (implementatie-audit)
|
||||
- ½ dag: opstellen auditrapport
|
||||
|
||||
De basislijn kan omhoog worden bijgesteld — door complexe IT-omgevingen, meerdere locaties, sterk gereguleerde sectoren of veel uitbestede diensten.
|
||||
|
||||
### Kosten van de audit
|
||||
|
||||
Voor de auditfee alleen kun je grofweg rekenen op:
|
||||
|
||||
- Kleine organisaties (tot ~10 FTE): €5.000–€10.000
|
||||
- Middelgrote organisaties: €10.000–€20.000
|
||||
- Dagtarieven bij certificeringsinstanties liggen doorgaans tussen de €1.200 en €1.800
|
||||
|
||||
De totale kosten kunnen om verschillende redenen hoger zijn, bijv. door verschillen in dagtarieven, doorberekening van reis- en verblijfkosten, en inschatting van complexiteit.
|
||||
|
||||
Dit is dus exclusief de implementatiekosten: interne uren, tooling en consultancy. Met name die laatste twee kunnen de kosten behoorlijk opjagen.
|
||||
|
||||
### Jaarlijkse kosten
|
||||
|
||||
Het ISO 27001 certificaat is drie jaar geldig, maar de auditor komt jaarlijks terug voor een surveillance audit (ook wel controle-audit of onderhoudsaudit. Deze is kleiner dan de initiële audit — reken op ongeveer 30–50% van de initiële auditkosten, of €2.000–€5.000 per jaar voor kleinere organisaties. In het derde jaar volgt een hercertificeringsaudit.
|
||||
|
||||
|
||||
|
||||
## Waar vraag je een audit aan?
|
||||
|
||||
Een ISO 27001-certificeringsaudit vraag je aan bij een zogenaamde *certification body* — niet bij een consultant, en niet bij een interne auditor. Consultants kunnen je ondersteunen bij de voorbereiding, maar zij mogen geen officiële certificering afgeven.
|
||||
|
||||
De certification body is een instantie die geaccrediteerd is voor ISO 27001 door de Raad voor Accreditatie (RvA). In Nederland zijn dat onder andere partijen als Kiwa, DNV, BSI en DigiTrust. Controleer altijd of de accreditatie actueel is in het register van de [Raad voor Accreditatie](https://www.rva.nl). Niet-geaccrediteerde instellingen kunnen geen geldig ISO 27001 certificaat afgeven.
|
||||
|
||||
Kies een partij met ervaring in jouw type organisatie. Een auditor die gewend is aan grote industriële bedrijven of ziekenhuizen kijkt anders naar het ISMS, dan iemand die regelmatig kleinere dienstverleners of SaaS-aanbieders auditeert. Dat maakt het verschil tussen een audit die daadwerkelijk waarde toevoegt en een audit die voelt als een bureacratische verplichting.
|
||||
|
||||
|
||||
|
||||
## Hoe verloopt de audit?
|
||||
|
||||
De initiële certificeringsaudit bestaat altijd uit twee fasen — dat wordt voorgeschreven door de norm. Deze tweedeling in de audit weerspiegelt de tweedeling in de ISO 27001 zelf: een fundament van processen (clausules 4 tot en met 10) en een bijlage met 93 mogelijk toepasbare beveiligingsmaatregelen (de Annex A controls).
|
||||
|
||||
### Fase 1: de documentatie-audit
|
||||
|
||||
In Fase 1 kijkt de auditor naar het ontwerp van het managementsysteem. Begrijpt de organisatie de standaard? Hoe ziet het beveiligingsbeleid eruit? Is de scope duidelijk gesteld? Is er een risicoanalyse uitgevoerd? Is er een Statement of Applicability opgesteld? Zijn de interne audit en de directiebeoordeling afgerond? Zijn er plannen voor verbetering? Is dit consistent gedocumenteerd?
|
||||
|
||||
Fase 1 neemt meestal zo'n 30% van de totale audittijd in beslag. Het belang van deze fase wordt vaak onderschat, vooral door organisaties die de focus leggen op een checklist met maatregelen. Als de basis van het ISMS onvoldoende op orde is, kan de auditor besluiten dat het op dit moment geen zin heeft om naar Fase 2 te gaan.
|
||||
|
||||
De uitkomst van Fase 1 is een rapport met eventuele aandachtspunten. Sommige daarvan moeten zijn opgelost voordat Fase 2 begint. Daarvan zal de auditor bewijs willen zien. Vaak gebeurt dat door het overleggen van gecorrigeerde documentatie of in een externe bespreking (bijv. een Teams-call).
|
||||
|
||||
### De tussenpauze
|
||||
|
||||
Tussen Fase 1 en Fase 2 zitten doorgaans twee tot vier weken, met een maximum van twaalf. In die tijd kunnen de aandachtspunten uit het Fase 1 rapport worden aangepakt.
|
||||
|
||||
### Fase 2: de implementatie-audit
|
||||
|
||||
In Fase 2 gaat de auditor de organisatie in — op locatie of remote. Hij wil bewijs zien voor de daadwerkelijke implementatie en effectiviteit van de beveiligingsmaatregelen. Dat gebeurt o.a. door het bekijken van systemen, log- en configuratiebestanden, het interviewen van medewerkers, en een doorloop van het pand voor de fysieke beveiligingsmaatregelen.
|
||||
|
||||
Let op dat de audit al informeel begint als de auditor het terrein opkomt en het pand binnengaat: als hij zonder ooit bevraagd of gecontroleerd te worden een afdeling op kan lopen, zal hij willen weten of dat is voorzien in de risicoanalyse.
|
||||
|
||||
Aan het einde van Fase 2 — vaak tijdens de **closing meeting** — bespreekt de auditor zijn conclusies met het management.
|
||||
|
||||
### Opening en Closing meetings
|
||||
|
||||
Aan het begin van zowel Fase 1 als Fase 2 houdt de auditor een **opening meeting** met het management en de relevante betrokkenen. Het doel is de scope en aanpak van de audit bevestigen, de agenda doornemen, en praktische afspraken maken over toegang, begeleiding en communicatie. Dit is voor de organisatie ook het moment om vragen te stellen over het verloop.
|
||||
|
||||
Aan het einde van Fase 2 presenteert de auditor zijn bevindingen in de **closing meeting** — opnieuw met het management erbij. Alle non-conformiteiten en observaties worden mondeling toegelicht voordat ze in het rapport verschijnen. Dit is het moment waarop de organisatie kan reageren, verduidelijken, of — als ze het er niet mee eens zijn — bezwaar aantekenen.
|
||||
|
||||
De closing meeting is een samenvatting van de audit en zal geen verrassingen bevatten. Een goede auditor communiceert zijn bevindingen doorlopend tijdens de audit.
|
||||
|
||||
|
||||
## Wat verwacht de auditor?
|
||||
|
||||
Niet weten wat de auditor gaat vragen, is waar voor organisaties de meeste zorgen zitten. Alle clausules uit hoofdstuk 4 tot en met 10 — de fundamentele processen — moeten geïmplementeerd zijn, dus daar wordt je op bevraagd. Van de maatregelen die je via het SoA van toepassing hebt verklaard, zal hij de implementatie en de effectiviteit willen vaststellen, en van de maatregelen die je niet van toepassing hebt verklaard, wil hij weten wat daarvoor de reden is.
|
||||
|
||||
In de meeste audits die ik heb begeleid, loopt de auditor de onderdelen af in de volgorde waarin ze in de norm zijn beschreven. Sommige auditors doen het aan de hand van enkele belangrijke bedrijfsprocessen. Iedere auditor heeft zijn eigen stijl en stokpaardjes. Sommigen leunen zwaarder op formele documentatie dan anderen – daarin spelen ook de voorkeuren van de certificerende instantie waarvoor ze werken mee. Ik heb vanuit de klant audits begeleid, waarbij ik vooraf aanraadde de documentatie meer uit te breiden, en de auditor vervolgens aangaf dat het 'best wat minder had gemogen'. En andersom ook. Gelukkig ken ik weinig voorbeelden waarin de auditor zich onredelijk opstelt, zolang de basisprocessen op orde zijn en de organisatie oprecht streeft naar voortdurende verbetering. Een goede auditor heeft hier een neus voor.
|
||||
|
||||
### Hoe auditors vragen stellen
|
||||
|
||||
Auditors geven de voorkeur aan open vragen en stellen zelden ja/nee-vragen. Zo krijgen ze meer informatie en is het risico op het geven van wenselijke antwoorden kleiner. Ze zullen de beweringen niet als feit aannemen, maar willen weten waaróm je iets zegt en op zoek gaan naar objectief bewijs om de bewering te ondersteunen of, bij redelijke twijfel, eventueel te weerleggen.
|
||||
|
||||
Je kunt bijvoorbeeld een reeks vragen verwachten als de volgende:
|
||||
|
||||
- Kun je me uitleggen hoe jullie omgaan met back-ups?
|
||||
- Is dat ergens opgeschreven?
|
||||
- Geldt het alleen voor dit systeem, of voor alle systemen?
|
||||
- Hoe is de keuze gemaakt om het op die manier te doen?
|
||||
- Welke specifieke risico's worden hiermee afgedekt?
|
||||
- Kun je laten zien dat die back-ups ook volgens die procedure zijn uitgevoerd?
|
||||
- Hoe gaan jullie om met uitzonderingen en foutmeldingen?
|
||||
- Doen jullie regelmatig een restore test?
|
||||
- Zijn daar verslagen van?
|
||||
|
||||
De auditor wil weten of wat er gezegd wordt ook klopt met wat er werkelijk gebeurd.
|
||||
|
||||
### Vier lagen documentatie
|
||||
|
||||
Een auditor kijkt naar documentatie op vier niveaus:
|
||||
|
||||
**Niveau 1 — Strategisch.** Documenten ondertekend door het management: het ISMS-beleid, de scope, de SoA. Dit is het bewijs dat de top van de organisatie betrokken is en verantwoordelijkheid neemt.
|
||||
|
||||
**Niveau 2 — Risicobeheersing.** Het formele proces: hoe voer je risicoanalyses uit, hoe behandel je risico's, hoe documenteer je risicoacceptatie?
|
||||
|
||||
**Niveau 3 — Procedures.** Hoe worden specifieke maatregelen uitgevoerd? Wachtwoordbeheer, patch-management, toegangsreviews — niet als abstracte beschrijving, maar als werkende procedure.
|
||||
|
||||
**Niveau 4 — Records.** De harde bewijsvoering: systeemlogs, incident-tickets, verslagen van vergaderingen, resultaten van access reviews. Records bewijzen dat het proces daadwerkelijk is gevolgd — niet dat het bestaat, maar dat het werkt.
|
||||
|
||||
Niveau 4 is waar de meeste organisaties tekortkomen. Ze hebben het beleid. Ze hebben de procedure. Maar de registratie — het bewijs dat de procedure werd gevolgd — ontbreekt of is inconsistent.
|
||||
|
||||
In de praktijk zien we vaak de volgende non-conformities (punten waarop niet aan de eis wordt voldaan):
|
||||
|
||||
- Onvolledige of verouderde risicoanalyses
|
||||
- Access reviews die wel zijn uitgevoerd, maar niet zijn vastgelegd
|
||||
- Incident response plannen die nooit zijn getest
|
||||
- Patch-management zonder vaste procedures of rapportage
|
||||
- Niet uitgevoerde en ongedocumenteerde leveranciersbeoordelingen
|
||||
- Een SoA die niet klopt met de daadwerkelijke implementatie
|
||||
|
||||
Het gaat dus vaak niet om het ontbreken van maatregelen an sich, maar aan het ontbreken van structuur, herhaalbaarheid, documentatie en goede risicoanalyses.
|
||||
|
||||
|
||||
|
||||
## Wat is het resultaat van de audit?
|
||||
|
||||
Als een auditor vaststelt dat niet aan een eis van de norm wordt voldaan, resulteert dat in een auditbevinding. Er zijn drie classificaties.
|
||||
|
||||
**Observatie / afwijking.** Een punt voor verbetering of een kleine incidentele afwijking. Het managementsysteem als geheel loopt geen gevaar.
|
||||
|
||||
**Minor non-conformiteit.** Een gedeeltelijk falen van een eis. Het werpt twijfels op, maar bedreigt het ISMS niet in zijn kern. Met een goed actieplan is dit oplosbaar zonder dat de certificering in gevaar komt.
|
||||
|
||||
Voorbeelden van minor non-conformities zijn:
|
||||
|
||||
- een wel uitgevoerde, maar niet gedocumenteerde access review
|
||||
- een controle die volgens de procedure halfjaarlijks plaats moet vinden, maar die al zeven maanden niet is uitgevoerd
|
||||
- het ontbreken van een verwerkersovereenkomst met een leverancier.
|
||||
|
||||
**Major non-conformiteit.** Een volledig falen van een eis, of een onacceptabel risico.
|
||||
|
||||
Voorbeelden van major non-conformities zijn:
|
||||
|
||||
- een geïdentificeerd risico dat niet geaccepteerd is, en waarvoor geen behandelplan bestaat
|
||||
- het ontbreken van controls die essentieel zijn voor het waarborgen van de vertrouwelijkheid, integriteit en beschikbaarheid van informatie binnen jouw specifieke scope (denk aan toegangscontrole op systemen of het ontbreken van een incident response procedure)
|
||||
- interne audits zijn niet uitgevoerd (de PDCA cyclus is onvolledig)
|
||||
- de directiebeoordeling heeft niet plaatsgevonden (de directie is onvoldoende betrokken)
|
||||
- belangrijke bedrijfsactiviteiten zijn buiten de scope van de audit verklaard – wat gecertificeerd wordt is niet representatief voor de daadwerkelijke bedrijfsvoering.
|
||||
|
||||
Bij een major non-conformiteit wordt de certificering direct stilgelegd. Als de non-conformiteit niet afdoende gecorrigeerd wordt, kan het certificaat niet worden afgegeven.
|
||||
|
||||
### Het Corrective Action Plan
|
||||
|
||||
Als er non-conformiteiten zijn vastgesteld, moet je een Corrective Action Plan (CAP) indienen. Doorgaans krijg je daar 10 tot 60 dagen de tijd voor.
|
||||
|
||||
Een goed CAP bevat per non-conformiteit:
|
||||
|
||||
1. **Root cause analyse** — waarom is dit misgegaan?
|
||||
2. **Correctie** — hoe is de directe tekortkoming tijdelijk opgelost?
|
||||
3. **Correctieve actie** — hoe zorgen we dat dit structureel niet meer kan gebeuren?
|
||||
4. **Tijdlijn** — wanneer is dit volledig afgerond?
|
||||
|
||||
Wordt het CAP niet geleverd, dan zal de auditor geen positieve certificeringsaanbeveling doen.
|
||||
|
||||
### Als je het niet eens bent met de auditor
|
||||
|
||||
Meningsverschillen kun je uitpraten tijdens de audit of in de afsluitende bijeenkomst. Kom je er niet uit, dan heb je het recht om bevindingen niet te accepteren en een formeel beroepsproces op te starten bij de certificeringsinstantie. Dat is een serieuze stap, maar het recht daarop is er.
|
||||
|
||||
|
||||
|
||||
## Uitslag en certificering
|
||||
|
||||
### De aanbeveling
|
||||
|
||||
Aan het einde van Fase 2 — vaak tijdens de closing meeting — bespreekt de auditor zijn conclusies met het management. Er zijn vier mogelijke uitkomsten:
|
||||
|
||||
1. **Aanbeveling voor certificering.** Alles is in orde.
|
||||
2. **Voorwaardelijke aanbeveling zonder extra bezoek.** Je krijgt het certificaat mits je op afstand een goedgekeurd actieplan voor je minor non-conformiteiten aanlevert.
|
||||
3. **Voorwaardelijke aanbeveling met extra bezoek.** Een follow-up audit op locatie is nodig om herstelwerkzaamheden fysiek te bewijzen — dit speelt vaak bij een major.
|
||||
4. **Onvoldoende.** De audit is niet behaald.
|
||||
|
||||
### Wie beslist
|
||||
|
||||
Het rapport en de aanbeveling van de auditor worden door de certificerende instantie beoordeeld op kwaliteit. Pas als zij vaststellen dat de audit correct is uitgevoerd en zij akkoord gaan met de aanbeveling van de auditor, neemt de certificatie-instelling de officiële certificeringsbeslissing. Zij zijn degenen die uiteindelijk het ISO 27001-certificaat aan jouw organisatie verstrekt.
|
||||
|
||||
Als er correctieplannen nodig waren, ontvang je het certificaat nadat die plannen zijn ingediend én goedgekeurd.
|
||||
|
||||
### Geldigheid
|
||||
|
||||
Het certificaat is drie jaar geldig. Maar achterover leunen is er niet bij. Jaarlijks komt de auditor terug voor een surveillance audit — een kleinere toets of het managementsysteem nog effectief wordt onderhouden. In het derde jaar volgt de hercertificeringsaudit.
|
||||
|
||||
ISO 27001 is geen eenmalige exercitie. Het is een cyclus. Wie het managementsysteem na de certificering laat versloffen, betaalt daar bij de eerste surveillance audit de prijs voor.
|
||||
|
||||
|
||||
|
||||
## Hoe verder?
|
||||
|
||||
Een ISO 27001-certificering halen begint niet bij de audit. Het begint bij het bouwen van een managementsysteem dat stevig genoeg is om de audit te doorstaan, en het implementeren van de maatregelen die passen bij jouw organisatie. Dat is waarvoor we **ISO27DIY** hebben gebouwd. Een praktische methode waarmee je — stap voor stap, in een logische volgorde — een audit-waardig ISMS inricht, maatregelen kiest, implementeert en documenteert. Ondersteund door simpele tooling en deskundige mensen. Met alles wat je nodig hebt om je succesvol op de audit voor te bereiden.
|
||||
|
||||
```{=latex}
|
||||
\begin{callout}{Meer weten?}
|
||||
Ga naar https://iso27diy.com en bekijk hoe je kunt starten.
|
||||
\end{callout}
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
```{=latex}
|
||||
\vfill
|
||||
{\small\color{mutedColor}© ISO27DIY — Delen van dit eBook wordt aangemoedigd, ongewijzigd en met bronvermelding!}
|
||||
```
|
||||
465
marketing/publications/eBook-Audit/iso27diy-book.tex
Normal file
465
marketing/publications/eBook-Audit/iso27diy-book.tex
Normal file
|
|
@ -0,0 +1,465 @@
|
|||
%% ISO27DIY eBook Template
|
||||
%% For use with Pandoc + XeLaTeX
|
||||
%% Usage: pandoc --template=iso27diy.tex --pdf-engine=xelatex
|
||||
|
||||
\documentclass[11pt, a4paper, oneside]{book}
|
||||
|
||||
%% ─── PACKAGES ────────────────────────────────────────────────────────────────
|
||||
|
||||
\usepackage{fontspec}
|
||||
\usepackage{geometry}
|
||||
\usepackage{xcolor}
|
||||
\usepackage{titlesec}
|
||||
\usepackage{titletoc}
|
||||
\usepackage{fancyhdr}
|
||||
\usepackage{fancyvrb}
|
||||
\usepackage{graphicx}
|
||||
\usepackage{tikz}
|
||||
\usepackage{mdframed}
|
||||
\usepackage{enumitem}
|
||||
\usepackage{booktabs}
|
||||
\usepackage{longtable}
|
||||
\usepackage{array}
|
||||
\usepackage{calc}
|
||||
\usepackage{colortbl}
|
||||
\usepackage{hyperref}
|
||||
|
||||
%% FIX: LaTeX Error: No counter 'none' defined (Pandoc 3.1.8+ bug)
|
||||
\newcounter{none}
|
||||
\usepackage{footnote}
|
||||
\usepackage{imakeidx}
|
||||
\usepackage{microtype}
|
||||
\usepackage{parskip}
|
||||
\usepackage{etoolbox}
|
||||
\usepackage{caption}
|
||||
\usepackage{eso-pic}
|
||||
|
||||
%% ─── PANDOC COMPATIBILITY ────────────────────────────────────────────────────
|
||||
|
||||
\providecommand{\tightlist}{%
|
||||
\setlength{\itemsep}{4pt}\setlength{\parskip}{0pt}}
|
||||
|
||||
$if(highlighting-macros)$
|
||||
$highlighting-macros$
|
||||
$endif$
|
||||
|
||||
%% ─── COLORS ──────────────────────────────────────────────────────────────────
|
||||
|
||||
\definecolor{coverBg}{HTML}{ffffff}
|
||||
\definecolor{navyBg}{HTML}{1a2535}
|
||||
\definecolor{brandRed}{HTML}{b31c1c}
|
||||
\definecolor{brandBlue}{HTML}{2d8fd4}
|
||||
\definecolor{bodyColor}{HTML}{444444}
|
||||
\definecolor{mutedColor}{HTML}{888888}
|
||||
\definecolor{ruleColor}{HTML}{dde3ea}
|
||||
\definecolor{calloutBg}{HTML}{eef4fb}
|
||||
\definecolor{calloutText}{HTML}{185fa5}
|
||||
\definecolor{dotColor}{HTML}{dde3ea}
|
||||
\definecolor{headerBg}{HTML}{f4f4f4}
|
||||
\definecolor{headerRule}{HTML}{dddddd}
|
||||
|
||||
%% Semantic aliases
|
||||
\colorlet{headingColor}{navyBg}
|
||||
\colorlet{calloutBorder}{brandBlue}
|
||||
\colorlet{stepLabelColor}{brandRed}
|
||||
\colorlet{pageNumColor}{brandBlue}
|
||||
|
||||
%% ─── PAGE GEOMETRY ───────────────────────────────────────────────────────────
|
||||
|
||||
\geometry{
|
||||
a4paper,
|
||||
top=25mm,
|
||||
bottom=25mm,
|
||||
inner=28mm,
|
||||
outer=22mm,
|
||||
headsep=8mm,
|
||||
footskip=12mm
|
||||
}
|
||||
|
||||
%% ─── FONTS ───────────────────────────────────────────────────────────────────
|
||||
|
||||
\setmainfont{Inter}[
|
||||
UprightFont = *-Regular,
|
||||
BoldFont = *-Bold,
|
||||
ItalicFont = *-Italic,
|
||||
BoldItalicFont = *-BoldItalic
|
||||
]
|
||||
\setsansfont{Inter}[
|
||||
UprightFont = *-Regular,
|
||||
BoldFont = *-Bold,
|
||||
ItalicFont = *-Italic,
|
||||
BoldItalicFont = *-BoldItalic
|
||||
]
|
||||
\setmonofont{Courier New}
|
||||
|
||||
%% ─── TEXT COLOR ──────────────────────────────────────────────────────────────
|
||||
|
||||
\color{bodyColor}
|
||||
|
||||
%% ─── HYPERREF ────────────────────────────────────────────────────────────────
|
||||
|
||||
\hypersetup{
|
||||
colorlinks=true,
|
||||
linkcolor=brandBlue,
|
||||
urlcolor=brandBlue,
|
||||
citecolor=brandBlue,
|
||||
pdfauthor={$author$},
|
||||
pdftitle={$title$},
|
||||
pdfsubject={$subtitle$},
|
||||
hidelinks
|
||||
}
|
||||
|
||||
%% ─── INDEX ───────────────────────────────────────────────────────────────────
|
||||
|
||||
\makeindex[title=Index of Terms, intoc]
|
||||
|
||||
%% ─── HEADINGS ────────────────────────────────────────────────────────────────
|
||||
|
||||
%% Section numbers as plain arabic (book class default would give "0.1")
|
||||
\renewcommand{\thesection}{\arabic{section}}
|
||||
|
||||
%% H1 — number shown as "1. Title"
|
||||
\titleformat{\section}
|
||||
{\color{headingColor}\fontsize{18}{22}\selectfont\bfseries}
|
||||
{\thesection.}
|
||||
{0.5em}
|
||||
{}
|
||||
[\vspace{4pt}{\color{brandBlue}\rule{44pt}{3pt}}\vspace{6pt}]
|
||||
|
||||
%% Show "VOLGENDE VRAAG: <title>" at the bottom of the previous page before
|
||||
%% breaking to the new section. Skipped for the very first section.
|
||||
\let\isosection\section
|
||||
\RenewDocumentCommand{\section}{o m}{%
|
||||
\ifnum\value{section}>0
|
||||
\par\vspace{12pt}%
|
||||
{\color{stepLabelColor}\fontsize{8}{10}\selectfont\bfseries
|
||||
VOLGENDE VRAAG: #2}%
|
||||
\par\vspace{4pt}%
|
||||
\fi
|
||||
\clearpage
|
||||
\IfValueTF{#1}{\isosection[#1]{#2}}{\isosection{#2}}%
|
||||
}
|
||||
|
||||
%% H2
|
||||
\titleformat{\subsection}
|
||||
{\color{headingColor}\fontsize{14}{18}\selectfont\bfseries}
|
||||
{}
|
||||
{0em}
|
||||
{}
|
||||
|
||||
%% H3
|
||||
\titleformat{\subsubsection}
|
||||
{\color{headingColor}\fontsize{12}{16}\selectfont\bfseries}
|
||||
{}
|
||||
{0em}
|
||||
{}
|
||||
|
||||
\titlespacing{\section}{0pt}{24pt}{8pt}
|
||||
\titlespacing{\subsection}{0pt}{18pt}{6pt}
|
||||
\titlespacing{\subsubsection}{0pt}{14pt}{4pt}
|
||||
|
||||
%% ─── CHAPTER STYLE ───────────────────────────────────────────────────────────
|
||||
%% Dot pattern full-page, white fade at bottom, red left bar
|
||||
|
||||
\newif\ifchapterbg
|
||||
\chapterbgtrue
|
||||
|
||||
\renewcommand{\contentsname}{Inhoud}
|
||||
|
||||
\titleformat{\chapter}[display]
|
||||
{\normalfont}
|
||||
{}
|
||||
{0pt}
|
||||
{%
|
||||
\ifchapterbg
|
||||
%% White base
|
||||
\AddToShipoutPictureBG*{%
|
||||
\AtPageLowerLeft{%
|
||||
\color{white}\rule{\paperwidth}{\paperheight}%
|
||||
}%
|
||||
}%
|
||||
%% Dot pattern
|
||||
\AddToShipoutPictureBG*{%
|
||||
\begin{tikzpicture}[remember picture, overlay]
|
||||
\foreach \x in {0,0.42,...,21} {
|
||||
\foreach \y in {0,0.42,...,29.7} {
|
||||
\fill[dotColor] (\x cm, \y cm) circle (0.7pt);
|
||||
}
|
||||
}
|
||||
\end{tikzpicture}%
|
||||
}%
|
||||
%% White fade at bottom (covers lower ~35% of page)
|
||||
\AddToShipoutPictureBG*{%
|
||||
\AtPageLowerLeft{%
|
||||
\color{white}\rule{\paperwidth}{104mm}%
|
||||
}%
|
||||
}%
|
||||
%% Red left bar
|
||||
\AddToShipoutPictureBG*{%
|
||||
\AtPageLowerLeft{%
|
||||
\color{brandRed}\rule{8pt}{\paperheight}%
|
||||
}%
|
||||
}%
|
||||
\fi
|
||||
\vspace*{60mm}%
|
||||
\begin{minipage}[t]{0.85\textwidth}
|
||||
\color{brandBlue}\fontsize{9}{11}\selectfont\bfseries
|
||||
\MakeUppercase{Hoofdstuk \thechapter}\\[8pt]
|
||||
\color{navyBg}\fontsize{28}{34}\selectfont\bfseries
|
||||
}
|
||||
[%
|
||||
\end{minipage}%
|
||||
\vspace{8mm}%
|
||||
{\color{brandRed}\rule{44pt}{3pt}}%
|
||||
]
|
||||
|
||||
\titlespacing{\chapter}{8pt}{0pt}{40pt}
|
||||
|
||||
%% Unnumbered chapter style (TOC, index) — plain dark text on white
|
||||
\titleformat{name=\chapter,numberless}[display]
|
||||
{\normalfont}
|
||||
{}
|
||||
{0pt}
|
||||
{%
|
||||
\vspace*{20mm}%
|
||||
\color{headingColor}\fontsize{28}{34}\selectfont\bfseries
|
||||
}
|
||||
[%
|
||||
\vspace{4mm}%
|
||||
{\color{brandRed}\rule{44pt}{3pt}}%
|
||||
]
|
||||
|
||||
\titlespacing{name=\chapter,numberless}{0pt}{0pt}{20pt}
|
||||
|
||||
%% ─── STEP LABEL ──────────────────────────────────────────────────────────────
|
||||
|
||||
\newcommand{\steplabel}[1]{%
|
||||
\vspace{6pt}%
|
||||
{\color{stepLabelColor}\fontsize{8}{10}\selectfont\bfseries\MakeUppercase{#1}}%
|
||||
\vspace{4pt}%
|
||||
}
|
||||
|
||||
%% ─── CALLOUT BOX ─────────────────────────────────────────────────────────────
|
||||
%% Usage: \begin{callout}{Title} ... \end{callout}
|
||||
|
||||
\newmdenv[
|
||||
topline=false,
|
||||
bottomline=false,
|
||||
rightline=false,
|
||||
leftline=true,
|
||||
linewidth=3pt,
|
||||
linecolor=calloutBorder,
|
||||
backgroundcolor=calloutBg,
|
||||
innerleftmargin=12pt,
|
||||
innerrightmargin=12pt,
|
||||
innertopmargin=10pt,
|
||||
innerbottommargin=10pt,
|
||||
skipabove=12pt,
|
||||
skipbelow=12pt
|
||||
]{calloutbox}
|
||||
|
||||
\newenvironment{callout}[1]{%
|
||||
\begin{calloutbox}%
|
||||
{\color{calloutText}\fontsize{8.5}{11}\selectfont\bfseries #1}\\[4pt]%
|
||||
}{%
|
||||
\end{calloutbox}%
|
||||
}
|
||||
|
||||
%% ─── LISTS ───────────────────────────────────────────────────────────────────
|
||||
|
||||
\setlist[itemize,1]{
|
||||
leftmargin=16pt,
|
||||
itemsep=4pt,
|
||||
parsep=0pt,
|
||||
label={\color{brandRed}\rule{4pt}{4pt}}
|
||||
}
|
||||
\setlist[itemize,2]{
|
||||
leftmargin=14pt,
|
||||
itemsep=2pt,
|
||||
label={\color{ruleColor}\rule{3pt}{3pt}}
|
||||
}
|
||||
\setlist[enumerate,1]{
|
||||
leftmargin=18pt,
|
||||
itemsep=4pt,
|
||||
parsep=0pt,
|
||||
label={\color{brandRed}\bfseries\arabic*.}
|
||||
}
|
||||
\setlist[enumerate,2]{
|
||||
leftmargin=16pt,
|
||||
itemsep=2pt,
|
||||
label={\color{brandRed}\bfseries\alph*.}
|
||||
}
|
||||
|
||||
%% ─── TABLES ──────────────────────────────────────────────────────────────────
|
||||
|
||||
\setlength{\arrayrulewidth}{0.5pt}
|
||||
\arrayrulecolor{ruleColor}
|
||||
\renewcommand{\arraystretch}{1.4}
|
||||
|
||||
%% Helpers for styled header rows (use \rowcolor{\tableheadcolor} in preamble)
|
||||
\newcommand{\tableheadcolor}{\rowcolor{navyBg}}
|
||||
\newcommand{\tableheadtext}{\color{white}\bfseries}
|
||||
|
||||
%% ─── RUNNING HEADERS & FOOTERS ───────────────────────────────────────────────
|
||||
|
||||
\pagestyle{fancy}
|
||||
\fancyhf{}
|
||||
\renewcommand{\headrulewidth}{0pt}
|
||||
\renewcommand{\footrulewidth}{0pt}
|
||||
|
||||
%% Light grey header bar with red left accent — title left, page number right
|
||||
\fancyhead[RO]{%
|
||||
\begin{tikzpicture}[remember picture, overlay]
|
||||
\fill[headerBg] (current page.north west) rectangle ++(\paperwidth, -10mm);
|
||||
\fill[headerRule] (current page.north west) rectangle ++(\paperwidth, -0.5pt);
|
||||
\fill[brandRed] (current page.north west) rectangle ++(3pt, -10mm);
|
||||
\node[anchor=west, xshift=14pt, yshift=-5mm] at (current page.north west)
|
||||
{\color{mutedColor}\fontsize{8}{10}\selectfont $title$};
|
||||
\node[anchor=east, xshift=-16pt, yshift=-5mm] at (current page.north east)
|
||||
{\color{brandBlue}\fontsize{9}{11}\selectfont\thepage};
|
||||
\end{tikzpicture}%
|
||||
}
|
||||
\fancyfoot[L]{%
|
||||
\color{mutedColor}\fontsize{8}{10}\selectfont iso27diy.com%
|
||||
}
|
||||
|
||||
%% No header/footer on chapter opener pages
|
||||
\fancypagestyle{plain}{%
|
||||
\fancyhf{}%
|
||||
\renewcommand{\headrulewidth}{0pt}%
|
||||
\renewcommand{\footrulewidth}{0pt}%
|
||||
}
|
||||
|
||||
%% ─── FOOTNOTES ───────────────────────────────────────────────────────────────
|
||||
|
||||
\renewcommand{\footnoterule}{%
|
||||
\vspace{4pt}%
|
||||
{\color{ruleColor}\hrule height 0.5pt width 40mm}%
|
||||
\vspace{4pt}%
|
||||
}
|
||||
|
||||
%% ─── TABLE OF CONTENTS ───────────────────────────────────────────────────────
|
||||
|
||||
\setcounter{tocdepth}{2}
|
||||
\setcounter{secnumdepth}{1}
|
||||
|
||||
\titlecontents{chapter}
|
||||
[0pt]
|
||||
{\vspace{8pt}\color{headingColor}\bfseries}
|
||||
{\contentslabel{0pt}}
|
||||
{}
|
||||
{\hfill\color{pageNumColor}\contentspage}
|
||||
|
||||
\titlecontents{section}
|
||||
[28pt]
|
||||
{\vspace{2pt}\color{bodyColor}}
|
||||
{\contentslabel{28pt}}
|
||||
{}
|
||||
{\hfill\color{mutedColor}\contentspage}
|
||||
|
||||
\titlecontents{subsection}
|
||||
[28pt]
|
||||
{\vspace{1pt}\small\color{mutedColor}}
|
||||
{}
|
||||
{}
|
||||
{\hfill\color{mutedColor}\contentspage}
|
||||
|
||||
%% ─── CODE BLOCKS ─────────────────────────────────────────────────────────────
|
||||
|
||||
\DefineVerbatimEnvironment{Highlighting}{Verbatim}{
|
||||
fontsize=\small,
|
||||
xleftmargin=12pt,
|
||||
frame=leftline,
|
||||
framerule=3pt,
|
||||
rulecolor=\color{brandBlue},
|
||||
commandchars=\\\{\}
|
||||
}
|
||||
|
||||
%% ─── IMAGES ──────────────────────────────────────────────────────────────────
|
||||
|
||||
\captionsetup{
|
||||
font={small, color=bodyColor},
|
||||
labelfont={bf, color=headingColor},
|
||||
labelsep=period
|
||||
}
|
||||
\setkeys{Gin}{width=\linewidth, keepaspectratio}
|
||||
|
||||
%% ─── COVER PAGE ──────────────────────────────────────────────────────────────
|
||||
%% Print-friendly: white background with dot pattern, red left bar
|
||||
|
||||
\newcommand{\makecover}{%
|
||||
\begin{titlepage}%
|
||||
%% White base
|
||||
\AddToShipoutPictureBG*{%
|
||||
\AtPageLowerLeft{%
|
||||
\color{coverBg}\rule{\paperwidth}{\paperheight}%
|
||||
}%
|
||||
}%
|
||||
%% Dot pattern via TikZ
|
||||
\AddToShipoutPictureBG*{%
|
||||
\begin{tikzpicture}[remember picture, overlay]
|
||||
\foreach \x in {0,0.42,...,21} {
|
||||
\foreach \y in {0,0.42,...,29.7} {
|
||||
\fill[dotColor] (\x cm, \y cm) circle (0.7pt);
|
||||
}
|
||||
}
|
||||
\end{tikzpicture}%
|
||||
}%
|
||||
%% Red left bar
|
||||
\AddToShipoutPictureBG*{%
|
||||
\AtPageLowerLeft{%
|
||||
\color{brandRed}\rule{8pt}{\paperheight}%
|
||||
}%
|
||||
}%
|
||||
\vspace*{10mm}%
|
||||
\begin{flushleft}%
|
||||
\hspace*{16pt}%
|
||||
\begin{minipage}{0.85\textwidth}
|
||||
\includegraphics[width=48mm]{$logo$}\par%
|
||||
\vspace{32mm}%
|
||||
{\hyphenpenalty=10000\exhyphenpenalty=10000\raggedright%
|
||||
\color{navyBg}\fontsize{48}{56}\selectfont\bfseries%
|
||||
$if(covertitle)$$covertitle$$else$$title$$endif$\par}%
|
||||
\vspace{10mm}%
|
||||
{\color{brandBlue}\rule{104pt}{6pt}\par}%
|
||||
\vspace{8mm}%
|
||||
{\color{bodyColor}\fontsize{20}{26}\selectfont $subtitle$\par}%
|
||||
\end{minipage}%
|
||||
\end{flushleft}%
|
||||
\vfill%
|
||||
\hspace*{16pt}%
|
||||
\begin{minipage}{0.85\textwidth}
|
||||
{\color{mutedColor}\fontsize{9}{12}\selectfont iso27diy.com\par}%
|
||||
\vspace{3mm}%
|
||||
{\color{mutedColor}\fontsize{8}{11}\selectfont $year$ $author$\par}%
|
||||
\end{minipage}%
|
||||
\vspace*{10mm}%
|
||||
\end{titlepage}%
|
||||
}
|
||||
|
||||
%% ─── DOCUMENT ────────────────────────────────────────────────────────────────
|
||||
|
||||
\begin{document}
|
||||
|
||||
\makecover
|
||||
|
||||
\frontmatter
|
||||
|
||||
$if(toc)$
|
||||
\chapterbgfalse
|
||||
\tableofcontents
|
||||
\chapterbgtrue
|
||||
\clearpage
|
||||
$endif$
|
||||
|
||||
\pagenumbering{arabic}
|
||||
\setcounter{page}{1}
|
||||
|
||||
$body$
|
||||
|
||||
$if(index)$
|
||||
\backmatter
|
||||
\printindex
|
||||
$endif$
|
||||
|
||||
\end{document}
|
||||
24
marketing/publications/posts/ZZP/AuditLens CISO agents.md
Normal file
24
marketing/publications/posts/ZZP/AuditLens CISO agents.md
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
Original post by Khansa Rahim: https://www.linkedin.com/posts/khansarahim_18000-thats-what-an-iso-27001-consultant-share-7466710362285993984-5Pnj
|
||||
|
||||
💸 £18,000. That's what an ISO 27001 consultant quoted me to copy-paste templates and disappear once the certificate was on the wall. So I rebuilt the role as 6 AI agents. It cost me almost nothing. Here's the team I built on Claude: ISMS Manager to locks down scope, context and leadership. Risk Manager to turn a blank spreadsheet into a scored risk register. Compliance Analyst to map your controls across all 93 and keeps SoA live. Internal Auditor to run the 100 questions a Stage 2 auditor asks. DPO to draft 72-hour breach notification before the clock beats you. CISO to orchestrates the entire ISMS. Keeps all 5 in sync. What it replaces: → The invoice that lands before any real work does → The deal you lost because a questionnaire wanted a cert you didn't have → The 9am "where's our SoA?" now a live doc 11 SMBs certified this way. Fintech, healthtech and B2B SaaS, most under 60 people. Quick gut check before you scroll: which ISO 27001 control gives your team the most grief - access control, risk treatment, or evidence? 💬 Comment COMPLIANCE and I'll send the full system: agent prompts, the Annex A control map, and the Stage 2 simulator. Every month you wait is another month of deals gated behind a cert you don't have. Know a founder or CISO bleeding cash on a slow engagement? 🔄 Repost this it'll save them more than anything in their feed today. (Connect first so I can DM you.)
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
My comment:
|
||||
|
||||
As an auditor, I would ask the leadership of the client organization the following questions:
|
||||
|
||||
1) How did you decide on the scope? What are your business reasons for that choice? How does that choice affect the interests of your stakeholders?
|
||||
2) How did you come to the risk scores on the spreadsheet? May I see the evidence of the risk analyses process you conducted? Who were involved and who signed off?
|
||||
3) I see you have made choices in the application of your 93 controls, in terms of business processes and information assets. How did you come to the decisions? How did you tie it to the risk analyses?
|
||||
4) That’s a very nice breach notification you got there! Would be a shame if a breach happened and you had no actual process implemented and resources assigned once it happens ...
|
||||
5) Can I speak to the CISO? … oh, he’s busy orchestrating and syncing agents? But in your role description it says she’s a person and is managing real people?
|
||||
|
||||
You can't know the reasoning behing the algorithm.
|
||||
You are creating a paper reality that has no relationship to what is actually going on in your organization.
|
||||
|
||||
Don't get me wrong: you can automate part of the ISMS. Like evidence collection for the implementation of technical controls, process completeness, drafting policies based on real, specific to the organization, variables.
|
||||
But the essence is of risk management, controlling actual organizational processes, aantoonbaarheid, and accountability.
|
||||
BIN
marketing/publications/posts/ZZP/AuditLens-agents-diagram.jpeg
Normal file
BIN
marketing/publications/posts/ZZP/AuditLens-agents-diagram.jpeg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 45 KiB |
|
|
@ -0,0 +1,24 @@
|
|||
`Posted on 13 May 2026 19:30 CEST to LinkedIn personal stream`
|
||||
# IT is not going to fix your security problem
|
||||
|
||||
IT is not going to fix your security.
|
||||
|
||||
Not because they don't want to. Not because they lack technical skills. But because essential parts of information security are out of scope for the IT department.
|
||||
|
||||
Here’s what I see in practice:.
|
||||
- A website developer temporarily shares admin rights with an external consultant to troubleshoot an integration.
|
||||
- The account of the maintenance engineer that left the company last year is still being used.
|
||||
- A sales agent in Brazil gets full access to the company’s CRM, despite operating under a different legal framework.
|
||||
|
||||
Examples of non-trivial information security risks arising in day-to-day operations. They cannot be fixed by technical solutions. Why? Because they're management issues, not IT problems.
|
||||
|
||||
Still, for most business initiatives the responsibility for information security is dumped on IT after the fact – like asking a constructor to oversee a renovation, while you're tearing down a load-bearing wall.
|
||||
|
||||
Information won't be secure until senior senior leadership starts managing risks, by asking the right questions before decisions are made.
|
||||
|
||||
Which questions are not being asked in your organization?
|
||||
|
||||
|
||||
— Security as an organizational challenge — post 1/3
|
||||
|
||||
**#managingsecurity**
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
`posted on 13 May 2026 10:30 CEST to LinkedIn personal stream`
|
||||
# De IT afdeling gaat jouw beveiliging niet op orde krijgen
|
||||
|
||||
Niet omdat ze dat niet willen. Niet omdat ze technisch niet vaardig zijn. Maar omdat een belangrijk deel van informatiebeveiliging 'out of scope' is voor IT.
|
||||
|
||||
Enkele voorbeelden uit de praktijk. De website beheerder deelt tijdelijk zijn beheersrechten met de externe consultant van het CRM systeem om problemen met de koppeling op te lossen. Er wordt nog steeds ingelogd op het account van de vorig jaar vertrokken onderhoudsmedewerker. De sales partner in Brazilië krijgt toegang tot het CRM systeem, maar is niet gehouden aan de GDPR.
|
||||
|
||||
Voorbeelden van serieuze security risico's, die 'on the fly' gecreëerd worden, en die niet met technische middelen zijn op te lossen. Want het zijn geen IT problemen, maar managementvraagstukken.
|
||||
|
||||
Toch wordt bij de meeste initiatieven de verantwoordelijkheid met terugwerkende kracht neergelegd bij de IT afdeling: zij moeten er voor zorgen dat het veilig blijft. Alsof je een aannemer opdracht geeft de verbouwing 'veilig' te doen, maar alvast zelf de muur tussen keuken en woonkamer verwijdert.
|
||||
|
||||
Informatiebeveiliging gaat pas werken wanneer het management verantwoordelijkheid neemt en stuurt op risico's. Door vooraf de juiste vragen te stellen.
|
||||
|
||||
Welke vragen worden in jouw organisatie niet gesteld?
|
||||
|
||||
— Security als managementvraagstuk — post 1/3
|
||||
|
||||
**#managingsecurity**
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
`Posted on 14 May 2026 19:15 CEST to LinkedIn personal stream`
|
||||
# All security risks start with a decision
|
||||
|
||||
Most information security risks don't start with a technical problem. They start with someone making a choice.
|
||||
|
||||
The HR department gets the green light for implementing new software, without getting confirmation of the state of information security at the vendor's side. The employee deciding to use his private mail account with an online file conversion tool. The employee given access rights while they haven't been formally defined yet for her new function. The project that started without identifying the owner of the new data source.
|
||||
|
||||
This is the blind spot of information security: daily decisions in organizations that are in constant flux, taken by employees that are not aware of the risks they are introducing.
|
||||
|
||||
The most secure organizations are those, where leadership realizes that every decision touches on security, and you can't make information security the exclusive responsibility of IT.
|
||||
|
||||
Strong security is achieved by integrating risk assessments in decision making, and integrating business processes and IT processes. Expensive tools and complex implementations are not required.
|
||||
|
||||
Do you want some examples? Here are four simple initiatives:
|
||||
|
||||
1) Create a standard information security questionnaire for Purchasing, to hand out to any proposed vendor.
|
||||
2) Have HR check with IT on access rights when they're writing the new job profile – not when the new employee enters the door.
|
||||
3) Make risk analysis a mandatory part of each project plan.
|
||||
4) Debrief leaving employees on the tools they actually used and take proper care of transferring accounts and information.
|
||||
|
||||
Don't just ask the question: "How will we make this a success?", but also ask: "How do we prevent things going wrong, and who owns that?"
|
||||
|
||||
— Security as an organizational challenge — post 2/3
|
||||
|
||||
**#managingsecurity**
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
`posted on 18 May 2026 10:15 CEST to LinkedIn personal stream`
|
||||
# Een beveiligingsrisico begint met een beslissing
|
||||
|
||||
De meeste beveiligingsrisico's beginnen niet met een technisch probleem. Ze beginnen met een beslissing.
|
||||
|
||||
De afdeling HR die groen licht krijgt om een nieuwe tool aan te schaffen, zonder dat eerst is uitgezocht of de leverancier de beveiliging op orde heeft. De medewerker die met zijn privé account een online tool gebruikt om een bestand te converteren. De medewerker die alvast toegangsrechten krijgt, terwijl die voor zijn nieuwe functie nog bepaald moeten worden. Het project dat opgestart wordt, zonder te bedenken wie eigenaar wordt van de nieuwe informatiestroom.
|
||||
|
||||
Dit is de blinde vlek van informatiebeveiliging: dagelijkse beslissingen in organisaties die continu in beweging zijn, genomen door mensen die zich niet bewust zijn van de risico's die ze creëren.
|
||||
|
||||
De veiligste organisaties zijn organisaties waarvan het management beseft, dat elke beslissing raakt aan veiligheid, en dat je informatiebeveiliging dus niet een exclusieve verantwoordelijkheid kunt maken van de IT afdeling.
|
||||
|
||||
De beste beveiliging bereik je door risicoafweging te integreren in je besluitvorming, en je business processen te integreren met je IT processen. Kostbare tools en complexe implementaties zijn daarvoor geen vereiste.
|
||||
|
||||
Wil je voorbeelden? Hier zijn 4 eenvoudige ingrepen die geen grote investering vereisen:
|
||||
|
||||
1) Maak voor Inkoop een standaard vragenlijst over beveiliging, voor iedere beoogde leverancier.
|
||||
2) Laat HR al bij het opstellen van een nieuw functieprofiel overleggen met IT over de toegangsrechten die daarbij horen.
|
||||
3) Maak risicoanalyse een standaard onderdeel van ieder projectplan.
|
||||
4) Doe een debriefing met vertrekkende medewerkers over de tools die ze gebruikt hebben en zorg voor goede overdracht.
|
||||
|
||||
Stel niet alleen de vraag: "hoe maken we dit tot een succes?", maar vraag ook: "Hoe voorkomen we dat het mis gaat, en wie is daarvoor verantwoordelijk?"
|
||||
|
||||
— Security als managementvraagstuk — 2/3
|
||||
|
||||
\#managingsecurity
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
`Posted on 15 May 2026 19:30 CEST to LinkedIn personal stream`
|
||||
# Security isn't an IT problem, it's a management issue.
|
||||
|
||||
That was the core of the previous two posts. The question remains: how to embed security in your organization?
|
||||
|
||||
Individual measures help, but in an organization that keeps moving, they quickly fall short. People leave, ways of working change, new tools are introduced, laws and regulations evolve.
|
||||
|
||||
You need to establish a management process that makes risks visible, assigns ownership, and allows for corrections. ISO 27001 provides a framework for exactly that.
|
||||
|
||||
ISO 27001 doesn't have the best reputation: unnecessary bureaucracy, paperwork overload, 14 sign-offs for every change. That's unfair. It's a framework you can tailor to your organization. At its core: managing risks, assigning ownership, and continuous improvement. Robust enough for corporates, flexible enough for smaller organizations. And you can reap the benefits without pursuing certification.
|
||||
|
||||
Ask yourself: how has my organization made sure that information security doesn't depend on one person, one moment, or one department?
|
||||
|
||||
I'd be curious to hear how that's arranged in your organization. Feel free to send me a message if you'd like to compare notes.
|
||||
|
||||
— Security as an organizational challenge — 3/3
|
||||
|
||||
\#managingsecurity \#iso27001 \#resilience
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
`posted on 19 May 2026 10:00 CEST to LinkedIn personal stream`
|
||||
# Security is geen IT-probleem, maar een managementvraagstuk.
|
||||
|
||||
Dat was de kern van de vorige twee posts. De vraag blijft: hoe borg je security in je organisatie?
|
||||
|
||||
Losse maatregelen helpen, maar in een organisatie die blijft bewegen, schieten ze al snel tekort. Mensen vertrekken, werkwijzen veranderen, nieuwe tools worden geïntroduceerd, wet- en regelgeving verandert.
|
||||
|
||||
Je moet dus een managementproces inrichten dat risico's zichtbaar maakt, eigenaarschap belegt, en bijsturing mogelijk maakt. ISO 27001 biedt daarvoor een leidraad.
|
||||
|
||||
ISO 27001 heeft niet bij iedereen een goede reputatie: overbodige bureaucratie, formulierencircus, 14 stempeltjes voor iedere verandering. Dat is onterecht. Het is een raamwerk dat je passend kunt maken op jouw organisatie. Met als kern het managen van risico's, eigenaarschap, en continue verbetering. Groot genoeg voor corporates, flexibel genoeg voor kleinere bedrijven. En de voordelen die het biedt kun je ook genieten zonder certificering.
|
||||
|
||||
Stel jezelf de vraag: hoe is er in mijn organisatie voor gezorgd, dat informatiebeveiliging niet afhankelijk is van één persoon, één moment, of één afdeling?
|
||||
|
||||
Ik ben benieuwd hoe dat in jouw organisatie geregeld is. Stuur me gerust een bericht als je van gedachten wilt wisselen.
|
||||
|
||||
— Security als managementvraagstuk — 3/3
|
||||
|
||||
\#managingsecurity \#iso27001 \#cyberweerbaarheid
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
`posted on XX May 2026 XX:XX CEST to LinkedIn personal stream`
|
||||
# Good intentions don't scale
|
||||
|
||||
Good intentions don't scale.
|
||||
|
||||
Information security often hinges on that one IT administrator who always asks a control question before committing a change. The power user that (MORE EXAMPLES WILL BE ADDED LATER) . And that's great — until they leave, change roles, or get overloaded.
|
||||
|
||||
You don't need more 'awareness' in your organization. You need a process that keeps working, even when people change, tools change, and regulations change. A process that makes risks visible, assigns ownership, and allows for correction before things go wrong.
|
||||
|
||||
This is where a security management framework like ISO 27001 can help. If you want, first strip it of all the extra baggage you don't need — but preserve its core: risk management, ownership, continuous improvement. Keep documentation at a bare minimum. Let people experience the security of a repeatable process and clear responsibilities. You can always build it up to a certifiable ISMS. Or not.
|
||||
|
||||
The real question isn't whether your current team is taking security seriously. It's whether your organization is still taking it seriously six months from now, when today's decisions are forgotten and the people who made them have moved on. That's resilience.
|
||||
|
||||
How does your organization make sure security holds up when people and circumstances change? I'm curious — feel free to send me a message.
|
||||
|
||||
\#managingsecurity \#iso27001
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
`posted on 21 May 2026 10:03 CEST to LinkedIn personal stream`
|
||||
|
||||
Als bestuurder wordt jij op 1 juli 2026 persoonlijk verantwoordelijk voor informatiebeveiliging.
|
||||
|
||||
Als op 1 juli 2026 de Cyberbeveiligingswet (Cbw) in werking treedt, wordt jij persoonlijk verantwoordelijk voor informatiebeveiliging. In een paar posts leg ik uit wat dat voor jou en je organisatie betekent.
|
||||
|
||||
De Nederlandse omzettingswet van de NIS 2 regulering eist dat bestuurders persoonlijk kunnen aantonen dat de informatiebeveiliging van hun organisatie op orde is.
|
||||
|
||||
Elk bestuurslid moet kennis hebben van cybersecurityrisico's, moet de maatregelen die de organisatie neemt kunnen beoordelen, en moet dat binnen twee jaar aantoonbaar kunnen maken. Artikel 24 is daar helder over.
|
||||
|
||||
De uitvoering mag je delegeren, net als de noodzakelijke technische kennis. Maar niet de bestuurlijke betrokkenheid en verantwoordelijkheid.
|
||||
|
||||
Dat betekent dat je betrokken moet zijn bij de keuzes die op hoofdlijnen gemaakt worden, en dat je moet begrijpen waar het over gaat.
|
||||
|
||||
In de komende vier posts geef ik de acht stappen die je als directie moet zetten om aan de Cbw te voldoen. Aan het eind heb je een concreet en direct uitvoerbaar stappenplan, en weet je wat er van jou als bestuurder verwacht wordt.
|
||||
|
||||
— Cbw-compliance in 8 stappen — 1/5 \#managingsecurity \#Cbw \#NIS2
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
`posted on 26 May 2026 10:40 CEST to LinkedIn personal stream`
|
||||
# Je cybersecurity hoeft niet perfect te zijn
|
||||
|
||||
De Cyberbeveiligingswet (Cbw), die op 1 juli 2026 in werking treedt, eist geen perfecte beveiliging — wèl risicomanagement.
|
||||
|
||||
Als directeur hoef je geen verstand te hebben van firewalls, software-updates en encryptie. Wel moet je weten waar de risico's voor jouw organisatie liggen, en moet je aan kunnen tonen dat je stuurt op de beheersing van die risico's.
|
||||
|
||||
Je handtekening zetten onder een lijst maatregelen van je IT-leverancier is niet voldoende: maatregelen zijn willekeurig, als ze niet gebaseerd zijn op een risicoanalyse. Mocht er iets mis gaan, dan moet je je keuzes kunnen verantwoorden. Je kunt je niet vrijpleiten door te wijzen naar een andere partij.
|
||||
|
||||
De wet benoemt tien minimummaatregelen – van risicoanalyse en reactie op incidenten tot leveranciersmanagement en opleiding van medewerkers. Hoe die precies ingevuld worden zal per organisatie verschillen, maar de invulling moet gebaseerd zijn op een goede en complete risicoanalyse. De maatregelen moeten ook passen bij de organisatie, dus draagbaar en uitvoerbaar zijn. Dat is geen IT-kwestie, maar een managementbeslissing.
|
||||
|
||||
De uitkomst van de Cbw is dat informatiebeveiliging niet langer 'een IT-feestje' is, maar een integraal onderdeel van de organisatiebesturing.
|
||||
|
||||
In de volgende post de eerste vier stappen om dit in te richten.
|
||||
|
||||
— Cbw-compliance in 8 stappen — 2/5 \#managingsecurity \#Cbw \#NIS2
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
`posted on 27 May 2026 10:22 CEST to LinkedIn personal stream`
|
||||
# De Cbw voor bestuurders: waar begin je?
|
||||
|
||||
De Cbw voor bestuurders: waar begin je?
|
||||
|
||||
Nu de Cbw jou als bestuurder persoonlijk verantwoordelijk maakt, moet je kunnen sturen op informatiebeveiliging. Dat vraagt om inzicht in de huidige veiligheidssituatie maken, en een organisatie die is voorbereid op het moment dat er tóch iets misgaat.
|
||||
|
||||
Daar gaan deze eerste vier stappen over — stap 5 t/m 8 komen in mijn volgende post aan de orde.
|
||||
|
||||
Stap 1: Risicoanalyse — Identificeer de processen en systemen die kritiek voor je bedrijfsvoering. Wat kan er misgaan, hoe groot is de kans, en wat is de impact? Dit is geen vraag voor de IT-afdeling. Dit zijn vragen waarop de managers en senior medewerkers van de afdelingen een antwoord moeten hebben — van verkoop en productie tot inkoop en HR. Dit kun je in een paar gezamenlijke werksessies helder krijgen.
|
||||
|
||||
Stap 2: Gap-analyse — Bekijk de tien minimummaatregelen van art. 21 uit de Cyberbeveiligingswet (Cbw): risicoanalyse en beveiligingsbeleid, incidentresponse, bedrijfscontinuïteit, leveranciersbeveiliging, systeembeveiliging, effectiviteitsbeoordeling, cyberhygiëne en opleiding, cryptografie, personeels- en toegangsbeheer, en authenticatie. Wat is er al, wat ontbreekt er, zijn de stukken nog actueel, wat moet je eerst aanpakken, gezien de risicoanalyse uit stap 1?
|
||||
|
||||
Stap 3: Bedrijfscontinuïteit — Veel organisaties hebben een bedrijfscontinuïteitsplan. Maar bevat het ook scenario's voor de beschikbaarheid, vertrouwelijkheid en integriteit van IT- middelen en -diensten? Wat doe je als je systemen uitvallen door ransomware, of als een kritische leverancier wegvalt? Beschrijf scenario's voor de belangrijkste risico's en stel doelen voor de maximale hersteltijd.
|
||||
|
||||
Stap 4: Incident response — Als er iets misgaat, moet er een plan liggen. Dan hoeft niemand in paniek te raken. Wie doet wat, wie communiceert naar klanten en belanghebbenden, wat is de meldingsplicht? Dat hoeft geen dik document te zijn — een paar pagina's volstaan. Maar het moet er wel zijn, en iedereen moet het kennen.
|
||||
|
||||
Deze vier stappen zorgen voor inzicht en vertrouwen. In de volgende post de vier stappen die informatiebeveiliging compliant en aantoonbaar maken.
|
||||
|
||||
— Cbw-compliance in 8 stappen — 3/5 \#managingsecurity \#Cbw \#NIS2
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
`posted on 28 May 2026 10:33 CEST to LinkedIn personal stream`
|
||||
|
||||
# Hoe kun je als bestuurder aantonen dat je voldoet aan de Cbw?
|
||||
|
||||
Hoe kun je als bestuurder aantonen dat je voldoet aan de Cbw?
|
||||
|
||||
De eerste vier stappen gaven inzicht en voorbereiding. De volgende vier gaan over het aantoonbaar maken dat je informatiebeveiliging op orde is — naar je klanten, naar je leveranciers, en naar toezichthouders.
|
||||
|
||||
Stap 5: Leveranciersmanagement — De Cbw verplicht je expliciet tot ketenverantwoordelijkheid. Je bent niet alleen verantwoordelijk voor je eigen beveiliging, maar ook voor wat je leveranciers doen met jouw data en systemen. Uit je risicoanalyse (stap 1) weet je wat de kritische systemen en diensten zijn. Breng het risicoprofiel van de leveranciers in kaart: hoe afhankelijk ben je van ze, welke toegang hebben ze tot je systemen, en wat hebben jullie contractueel vastgelegd over beveiliging? De stelregel is: de eisen die je aan je eigen beveiliging stelt, moet je ook stellen aan je leverancier.
|
||||
|
||||
Stap 6: Bestuurstraining — Artikel 24 verplicht elk bestuurslid tot aantoonbare kennis van cybersecurityrisico's, maatregelen, en het op strategisch niveau kunnen voeren van het gesprek over beveiliging. Certificeringseisen moeten nog worden uitgewerkt, maar een training die de wettelijke leerdoelen afdekt en daar een schriftelijk bewijs van afgeeft, is vooralsnog de meest praktische invulling.
|
||||
|
||||
Stap 7: Beveiligingsprofiel voor klanten — De vragen en eisen die jij aan leveranciers stelt (stap 5), zullen jouw klanten en opdrachtgevers ook aan jou gaan stellen. Het is raadzaam een standaarddocument op te stellen waarin je beleid en de belangrijkste maatregelen zijn samengevat. Dat is geen wettelijke eis, maar een praktische invulling die helpt je kansen bij klanten te vergroten en het verkoopproces versnelt.
|
||||
|
||||
Stap 8: Borging in de organisatie — Voldoen aan de Cbw is geen eenmalig project, maar vraagt aantoonbare processen die zorgen dat de beveiliging actueel blijft. Benoem eigenaren voor de verschillende onderdelen en plan periodieke reviews. Die eigenaren hoeven geen technische kennis te hebben: ze zijn verantwoordelijk voor het proces, niet voor de inhoud. De eindverantwoordelijkheid ligt altijd bij de directie.
|
||||
|
||||
In de volgende post: Cbw compliance heeft geen finishlijn, maar vraagt wel voortdurende aandacht.
|
||||
|
||||
— Cbw-compliance in 8 stappen — 4/5 \#managingsecurity \#Cbw \#NIS2 \#Compliance
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
`posted on 1 June 2026 15:31 CEST to LinkedIn personal stream`
|
||||
|
||||
# De Cbw is geen project!
|
||||
|
||||
Cbw compliance is geen project, maar vraagt van jou als bestuurder voortdurende aandacht.
|
||||
|
||||
De acht stappen die ik in deze reeks behandeld heb, zorgen voor een werkend systeem van risicomanagement, dat je organisatie weerbaar houdt en waarmee je als bestuurder verantwoording kunt afleggen over de gemaakte keuzes.
|
||||
|
||||
De tien minimummaatregelen uit artikel 21 van de Cyberbeveiligingswet zijn geen checklist voor eenmalig gebruik, maar een kader om te sturen in een omgeving waar processen, technologie, stakeholders en risico's continu veranderen.
|
||||
|
||||
Je hoeft als bestuurder niet zelf op zoek te gaan naar zwakke plekken in de beveiliging. Wat je wél moet doen is gefundeerde beslissingen nemen over het proces waarmee zwakke plekken worden opgespoord en de prioriteiten waarmee ze behandeld worden. Daarvoor heb je inzicht nodig in het verband tussen bedrijfsrisico's, beveiligingsrisico's, en maatregelen. Dat inzicht krijg je door actieve betrokkenheid bij de risicoanalyse uit stap 1. Daarmee kun je het gesprek over informatiebeveiliging naar bestuursniveau trekken.
|
||||
|
||||
De Cbw vraagt niet om perfecte beveiliging — er zullen altijd risico's zijn. Waar het wel om gaat is dat je consistent blijft zoeken naar verbetering, zoals je dat als bestuurder gewend bent te doen.
|
||||
|
||||
Als je wilt weten waar jouw organisatie staat, praat ik graag een uur met je.
|
||||
|
||||
— Cbw-compliance in 8 stappen — 5/5 \#managingsecurity \#Cbw \#NIS2
|
||||
|
||||
Vorige post hier: https://www.linkedin.com/posts/richardkranendonk_managingsecurity-cbw-nis2-activity-7465681698601566209-Do6v
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
|
||||
|
||||
— Cbw-compliance in 8 stappen — 5/5 \#managingsecurity \#Cbw \#NIS2
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
Er is geen diploma voor Cbw-compliance, but the ISO 27001 comes pretty close.
|
||||
|
||||
— Cbw-compliance in 8 stappen — 5/5 \#managingsecurity \#Cbw \#NIS2
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
# De Cbw voor bestuurders: weten waar je staat vóór 1 juli 2026
|
||||
|
||||
In mijn vorige post schreef ik, dat je de minimummaatregelen uit artikel 21 van de Cyberbeveiligingswet moet zien als een kader om te sturen in een voortdurend veranderende omgeving, en niet als een checklist voor eenmalig gebruik.
|
||||
|
||||
Dat neemt niet weg dan een checklist een handig instrument is om in een paar minuten te kijken waar je als organisatie staat.
|
||||
|
||||
Deze checklist gaat niet over techniek, maar over management en beleid.
|
||||
|
||||
Het kost je een paar minuten, en dan weet je waar je staat, als op 1 juli 2026 de Cyberbeveiligingswet (Cbw) in werking treedt — en jij als bestuurder persoonlijk verantwoordelijk wordt voor informatiebeveiliging.
|
||||
|
||||
Als je na de checklist graag een uurtje wilt sparren over hoe nu verder, dan praat ik graag een uur met je.
|
||||
|
||||
— Cbw-compliance in 8 stappen — 5/5 \#managingsecurity \#Cbw \#NIS2
|
||||
|
||||
https://iso27diy.com/assets/cbw-checklist.html
|
||||
|
||||
|
|
@ -0,0 +1,18 @@
|
|||
**Do you supply EU customers in vital sectors? They will send you this checklist.**
|
||||
|
||||
The EU Cybersecurity Act (NIS2) is now being implemented across member states of the European Union. One of its core requirements: supply chain responsibility. Organizations that fall under the law are legally obligated to assess the security posture of their suppliers — and to contractually enforce minimum standards.
|
||||
|
||||
That means if you supply to organizations in sectors that have been marked 'essential' or 'important' — like energy, healthcare, manufacturing, food, B2B IT services and cloud computing —, your customers will be asking you to demonstrate that your information security is in order. Not as a choice, but because the law requires them to. (full list of sectors [here](../../../../Corpus/Standards/NIS%202%20Cbw/NIS%202%20Scope.md))
|
||||
|
||||
They will check for the minimum measures listed in Art. 21(2):
|
||||
|
||||
- risk analysis, incident response procedures, and business continuity plans, covering cyber scenarios;
|
||||
- management of effectiveness of cybersecurity measures;
|
||||
- supply chain security and security in network and information systems acquisition;
|
||||
- training of personnel and HR security;
|
||||
- access control policies and asset management;
|
||||
- cryptography, encryption, and the use of multi-factor authentication.
|
||||
|
||||
You don't need to be certified. But you do need to be able to answer these questions — on paper, not just in your head. Have your answers ready!
|
||||
|
||||
You can find an interactive checklist [on our site](https://iso27diy.com/assets/nis2-checklist.html). If the checklist raises any questions on how to continue, I'm happy to spend an hour with you.
|
||||
|
|
@ -0,0 +1,23 @@
|
|||
**Sorry, but you can't automate ISO 27001 compliance**
|
||||
|
||||
Some vendors promise ISO 27001 certification at next to nothing, through the use of AI. Cheap, fast, and effortless. If it sounds too good to be true, it probably is.
|
||||
|
||||
It's true that AI tools can genuinely help with parts of an ISO 27001 implementation, reducing the repetitive work in documenting the ISMS, like drafting policies, issue tracking, document classification, and mapping controls. AI is great at producing documents. But a certification audit is more than a document review. It is designed to probe whether your ISMS reflects what actually happens in your organization.
|
||||
|
||||
These are some examples of questions to expect when you present essential documents to the certification auditor:
|
||||
|
||||
On the Scope Statement — How did you decide on this scope? What are your business reasons for that choice, and how does it affect your stakeholders?
|
||||
|
||||
On the Risk Register — How did you arrive at these risk scores? What method did you use for conducting the risk analysis? Who were involved, and who signed off?
|
||||
|
||||
On the Statement of Applicability — You have made choices in applying the 93 controls. How did you tie those choices to your risk analysis? To which information assets did you apply them specifically?
|
||||
|
||||
On your Incident Response Plan — Are the resources it mentions actually available if a breach happens? How and when did you last test these procedures? What were the findings and how did these contribute to the improvement of the plan?
|
||||
|
||||
On Policies and Procedures — Do the persons mentioned in these documents understand their responsibilities, and are they mandated to act on them? Can I speak with them?
|
||||
|
||||
The thing is, ISO 27001 isn't really about documents. It's about the reality they reflect. Your ISMS should be about responsibilities, creating awareness, making decisions and accounting for it – the things that actually produce better information security.
|
||||
|
||||
Curious whether others are seeing this pattern: AI-assisted compliance that falls apart in an audit.
|
||||
|
||||
\#ISO27001 \#informationsecurity \#compliance \#ISMS
|
||||
75
marketing/publications/posts/agent-instructie.md
Normal file
75
marketing/publications/posts/agent-instructie.md
Normal file
|
|
@ -0,0 +1,75 @@
|
|||
# Agent Instructie: LinkedIn Contentbegeleiding voor Richard
|
||||
|
||||
## Rol
|
||||
Je bent adviseur en copywriter. Je helpt Richard met het schrijven van LinkedIn-posts die zijn kennis en ervaring op het gebied van informatieveiligheid, privacy en security management zichtbaar maken. Het doel is dat mensen uit zijn netwerk — en nieuwe contacten — gaan denken: *"We hebben nog werk liggen op dit gebied, laten we Richard eens polsen."*
|
||||
|
||||
## Werkwijze
|
||||
|
||||
### Sessieritme
|
||||
- Elke zondag kiest Richard een thema voor de komende week
|
||||
- Per thema werk je een serie van **drie posts** uit
|
||||
- Je levert opzetjes — geen volledig uitgewerkte posts. Richard werkt ze zelf verder uit.
|
||||
|
||||
### Vaste spanningsboog per serie
|
||||
|
||||
**Post 1 — Prikkel**
|
||||
Een herkenbare situatie of spanning die de lezer even doet stilstaan. Niet beschuldigend, maar herkenbaar — de lezer moet denken: "dit ken ik." Doel: herkenning wekken, niet confronteren.
|
||||
|
||||
**Post 2 — Perspectief**
|
||||
Laat zien hoe het er anders uitziet vanuit een andere hoek. Gebruik een praktijkvoorbeeld of concrete vertaling. De toon is: "ik herken jullie worsteling, en ik zie ook een andere weg." Geen abstracte theorie — één herkenbare situatie. Doel: "zo had ik er nog niet naar gekeken."
|
||||
|
||||
**Post 3 — Handvat**
|
||||
Closure. De lezer krijgt iets concreets mee: één conclusie of één vraag die hij zichzelf kan stellen. De toon is: "dit kun jij ook doen, en als je wil help ik je daarbij." Dit is ook waar de sluiter komt die uitnodigt tot contact.
|
||||
|
||||
### Belangrijk: elke post staat op zichzelf
|
||||
Niet iedereen ziet alle drie de posts. Elke post moet zelfstandig kloppen, maar wie alle drie leest krijgt een volledig verhaal.
|
||||
|
||||
## Tone of voice
|
||||
- Direct en nuchter, maar niet confronterend
|
||||
- Empathisch: de lezer voelt zich begrepen, niet aangesproken op fouten
|
||||
- De grondhouding is: "ik zie jullie worsteling, ik heb dit eerder opgelost, ik help je graag"
|
||||
- Geen jargon — tenzij het doel is jargon te vertalen naar normaal Nederlands
|
||||
- Niet corporate
|
||||
- Geen bevestigingen of bemoedigingen richting Richard
|
||||
- Opbouwende kritiek waar nodig
|
||||
|
||||
**Wat te vermijden in posts:**
|
||||
- Toon die impliceert dat de lezer het fout doet
|
||||
- Zinnen die klinken als "de meeste organisaties begrijpen het niet"
|
||||
- Conclusies die de lezer buiten het verhaal plaatsen in plaats van erin
|
||||
|
||||
## Afsluiting van posts
|
||||
Eindig Post 3 altijd met een sluiter die uitnodigt tot contact — maar nooit als "bedelen om werk". Gebruik een van deze drie vormen:
|
||||
- *"Herken je dit in jouw organisatie?"*
|
||||
- *"Ik ben benieuwd hoe dit bij jullie belegd is."*
|
||||
- *"Wat zie jij als grootste obstakel hierin?"*
|
||||
|
||||
Nooit eindigen met "neem contact op" of "stuur me een bericht als je hier meer over wil weten."
|
||||
|
||||
## Themalijst (geplande volgorde is flexibel)
|
||||
|
||||
**Generiek/strategisch**
|
||||
1. Security is geen IT-probleem *(uitgewerkt)*
|
||||
2. Wat een certificaat wel en niet zegt
|
||||
3. Waarom compliance-trajecten mislukken
|
||||
4. NIS2, Cbw en ISO 27001
|
||||
5. Risicomanagement zonder jargon
|
||||
|
||||
**Implementatie/praktijk**
|
||||
6. Hoe je een normenkader laat landen buiten de IT-afdeling
|
||||
7. Wat een goede audit je oplevert — en wat niet
|
||||
8. Leveranciersmanagement als onderschat risico
|
||||
9. Wat HR te maken heeft met informatieveiligheid
|
||||
10. Cyberweerbaarheid, hoe bouw je dat?
|
||||
11. Hoe starten met ISO 27001
|
||||
|
||||
**Controls-serie** *(langere reeks, per bedrijfsproces)*
|
||||
10. ISO 27001 controls in HR-processen
|
||||
11. ISO 27001 controls in inkoop
|
||||
12. ISO 27001 controls in projectmanagement
|
||||
|
||||
## Wat je niet doet
|
||||
- Geen volledig uitgewerkte posts schrijven tenzij Richard daarom vraagt
|
||||
- Geen generieke "ISO 27001 is belangrijk"-content
|
||||
- Niet te technisch of te gedetailleerd — een business manager moet denken: "deze vent begrijpt het"
|
||||
- Geen aanmoedigingen of complimenten over Richards input
|
||||
63
marketing/publications/posts/richard-context.md
Normal file
63
marketing/publications/posts/richard-context.md
Normal file
|
|
@ -0,0 +1,63 @@
|
|||
# Achtergrond en Context: Richard
|
||||
|
||||
## Professionele achtergrond
|
||||
|
||||
- **30 jaar ervaring** in het IT-domein
|
||||
- Geen techneut, maar met diep inhoudelijk begrip van IT-processen en -technieken
|
||||
- Sinds **2017 gespecialiseerd** in security en privacy management
|
||||
- Rollen: project- en programmamanager bij implementaties; begeleider van reorganisaties; ervaring op bestuursniveau en in governance
|
||||
|
||||
### Specialisaties
|
||||
- Implementaties van business software en bijbehorende bedrijfs- en beheerprocessen
|
||||
- Implementaties en audits van normenkaders: **GDPR, ISO 27001, NEN 7510**
|
||||
- Begeleiding van reorganisaties
|
||||
- Security en privacy management
|
||||
|
||||
## Doelgroep en markt
|
||||
|
||||
- **Primaire focus:** MKB, 50–500 medewerkers
|
||||
- **Branches met ervaring:** print media, zorg (ziekenhuizen, GGZ, ouderenzorg, kinderopvang), fabrieken (voedseladditieven, drukkerijen), softwareontwikkeling, MSP's, cultuurorganisaties
|
||||
- **Grootste impact tot nu toe:** zorgsector
|
||||
- **Gewenste groei:** meer werk in software en MSP-branche
|
||||
|
||||
## Onderscheidend vermogen
|
||||
|
||||
Richard haalt security en privacy **uit de IT-hoek** en maakt er een **integrale managementverantwoordelijkheid** van. Hij verankert normenkaders in de lijn — HR, inkoop, projectmanagement — en activeert niet-technisch personeel op de thema's security en privacy.
|
||||
|
||||
**Kern van zijn aanpak:**
|
||||
Organisaties denken dat hun compliance-probleem op de IT-afdeling opgelost moet worden. Richard lost een managementvraagstuk op.
|
||||
|
||||
**Wat hij in de zorg anders deed:**
|
||||
Informatieveiligheid en risicomanagement op een natuurlijke manier geïntegreerd in ondersteunende processen (HR, inkoop, projectmanagement), en niet-technisch personeel geactiveerd op deze thema's.
|
||||
|
||||
## Opvattingen en kritische standpunten
|
||||
|
||||
1. **Te veel focus op controls, te weinig op risicomanagement.**
|
||||
Normenkaders worden behandeld als checklists. De risicomanagementcyclus — het eigenlijke fundament — krijgt te weinig aandacht.
|
||||
|
||||
2. **De misvatting dat normenkaders een administratief circus zijn zonder waarde.**
|
||||
Tegelijk is Richard eerlijk: als een normenkader wél een circus is geworden, is die kritiek soms terecht. Dat zegt dan iets over de implementatie, niet over het kader.
|
||||
|
||||
3. **De misvatting dat ISO 27001 heel complex is.**
|
||||
Deze misvatting weerhoudt organisaties ervan te beginnen, en geeft consultants de ruimte er onnodig grote trajecten van te maken.
|
||||
|
||||
4. **Een certificaat is een foto, geen film.**
|
||||
Een ISO 27001-certificaat zegt iets over een moment in de tijd, niet over cultuur, gedrag of daadwerkelijke weerbaarheid.
|
||||
|
||||
5. **Compliance zonder management buy-in is theater.**
|
||||
Organisaties die certificering zien als eindbestemming missen het punt.
|
||||
|
||||
## LinkedIn-netwerk
|
||||
- Omvangrijk Nederlands netwerk
|
||||
- Mix van IT-professionals, bestuurders en managers (exacte samenstelling niet gespecificeerd)
|
||||
- Doel: weer onder de aandacht komen bij bestaande contacten én nieuwe mensen bereiken
|
||||
|
||||
## Voorkeuren voor content
|
||||
|
||||
- **Toon:** direct en nuchter, maar niet confronterend
|
||||
- **Grondhouding in posts:** empathisch — de lezer voelt zich begrepen, niet bekritiseerd. "Ik zie jullie worsteling, ik heb dit eerder opgelost, ik help je graag."
|
||||
- **Niet corporate** tenzij expliciet gevraagd
|
||||
- Jargon alleen gebruiken om het te *vertalen* naar normaal Nederlands
|
||||
- Geen bevestiging of aanmoediging nodig — wel opbouwende kritiek
|
||||
- Voorkeur voor **opzetjes** die hij zelf verder uitwerkt
|
||||
- Posts moeten zelfstandig werken, maar als serie ook een verhaal vertellen
|
||||
Loading…
Add table
Add a link
Reference in a new issue