Initial commit
This commit is contained in:
commit
570d74d4dd
67 changed files with 4609 additions and 0 deletions
BIN
.DS_Store
vendored
Normal file
BIN
.DS_Store
vendored
Normal file
Binary file not shown.
26
About/Value Proposition Canvas for iso27DIY.md
Normal file
26
About/Value Proposition Canvas for iso27DIY.md
Normal file
|
|
@ -0,0 +1,26 @@
|
|||
# Value Proposition Canvas
|
||||
|
||||
![[Value Proposition Canvas.jpg]]
|
||||
**Products & Services**:
|
||||
* **Guided Implementation System**: 50+ micro-sessions guiding the process.
|
||||
* **GRC Tooling**: Easy-to-use system for managing artifacts, risks, and assets.
|
||||
* **AI Assistant**: Generates tailor-made information security policies.
|
||||
* **Controls Library**: Practical, "Plain English" examples for all 94 Annex A controls.
|
||||
* **Expert Support**: On-demand access to experienced ISO 27001 consultants.
|
||||
* **Preliminary Audits**: Sessions with certified auditors to prepare for certification.
|
||||
|
||||
**Pain Relievers**:
|
||||
* **Time & Cost Efficiency**: The guided, templated system and tooling reduce the need for expensive consultants or dedicated full-time staff.
|
||||
* **Removes Documentation Burden**: The AI assistant and structured system eliminate the "nightmare" of creating policies from scratch, ensuring they are tailored and practical, not generic and unwieldy.
|
||||
* **Mitigates Audit Fear**: The Controls Library and Preliminary Audits directly address the ambiguity of the framework, providing clarity on what is "enough" to pass.
|
||||
|
||||
**Gain Creators**:
|
||||
* **Strategic Advantage**: Enables SMEs to achieve certification cost-effectively, unlocking business opportunities and building trust.
|
||||
* **Confidence & Clarity**: The guided system, clear controls library, and preliminary audits build confidence throughout the implementation process.
|
||||
* **Operational Integration**: By providing a clear process and tailored tools, the solution encourages the ISMS to become an integrated part of business operations rather than an isolated, bureaucratic system.
|
||||
|
||||
**Gains:**
|
||||
|
||||
**Customer Jobs:**
|
||||
|
||||
**Pains:**
|
||||
43
AuditGlue/AuditGlue Workflows.md
Normal file
43
AuditGlue/AuditGlue Workflows.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# AuditGlue Workflows
|
||||
|
||||
## Volgen van een Session
|
||||
|
||||
- gebruiker klikt uit het Sessions-menu een les aan
|
||||
- gebruiker kan een Reference-link aanklikken voor achtergrondinformatie/ voorbeelden, een modal opent
|
||||
- een Sessie kan 0 of 1 taak hebben.
|
||||
- de taak kan bestaan uit het invoeren van waarden (tekst) of het uploaden van een document.
|
||||
- Zie voor nader uitleg over het Werken met Taken hieronder.
|
||||
|
||||
## Re-visiting a Session
|
||||
|
||||
- gebruiker klikt uit het Sessions-menu een les aan
|
||||
- als er al eerder waarden (tekst) is ingevoerd, of al eerder een document geüpload is, wordt dit uit de database opgehaald en kan de gebruiker wijzigingen aanbrengen (cq. een nieuwe versie van het document uploaden)
|
||||
|
||||
## Triggering an Automation
|
||||
|
||||
- Een Automation is een ondersteunende tool bij een Task – bijv. het genereren van een ‘Acceptable Use Policy’.
|
||||
- De Automation wordt in de AuditGlue UI getoond als een Start-button met een omschrijving/verklaring van wat de Automation doet.
|
||||
- De Start-button triggert een workflow in n8n.
|
||||
- In AuditGlue is een indicatie ‘Working …’ te zien.
|
||||
- De workflow doet typisch het volgende:
|
||||
- - er wordt input opgehaald vanuit de database (*).
|
||||
- deze input wordt samen met een prompt naar een LLM gestuurd.
|
||||
- het resultaat wordt als document opgeslagen in de database (formaat ntb, de gebruiker moet de content kunnen wijzigen)
|
||||
- In AuditGlue is een knop ‘Edit Result’ te zien.
|
||||
- De gebruiker kan de tekst indien gewenst aanpassen (en opslaan)
|
||||
- De gebruiker kan de taak (waarvan de Automation een onderdeel is) markeren als Completed
|
||||
|
||||
(*) Er zitten hier dus afhankelijkheden en configuratie-uitdagingen:
|
||||
|
||||
- de input voor een Automation bestaat uit de resultaten van eerder uitgevoerde taken
|
||||
- die taken moeten als ‘Completed’ gemarkeerd zijn
|
||||
- er moet ergens gedefinieerd zijn welke input nodig is voor een Automation
|
||||
- er moet ergens een prompt gedefinieerd zijn
|
||||
|
||||
## Werken met Taken
|
||||
|
||||
Een taak heeft één van de volgende 4 statussen:
|
||||
1. Status Backlog: de taak moet nog uitgevoerd worden, maar niet nu.
|
||||
2. Status ToDo: de gebruiker heeft de taak toegevoegd aan haar persoonlijke werklijst – de taak is zichtbaar in de sidebar als een 'To Do'.
|
||||
3. Status Done: de gebruiker vindt de taak voldoende afgerond om verder mee te gaan – deze status is de vereiste voor `automation_depends_on`.
|
||||
4. Status Finalized: de taak is 'ready for audit' – deze status wordt gebruikt in een (nog te ontwerpen) voortgangsoverzicht waarop de gebruiker kan zien in hoeverre zij klaar is voor de audit.
|
||||
19
AuditGlue/Conceptual ERD.md
Normal file
19
AuditGlue/Conceptual ERD.md
Normal file
|
|
@ -0,0 +1,19 @@
|
|||
# Conceptual ERD
|
||||
|
||||
|
||||
```mermaid
|
||||
erDiagram
|
||||
Session ||--o| Task : "has 0..1"
|
||||
Session }o--o{ NormArticle : "has 0..n"
|
||||
Task ||--o| FormValues : "has 0..1"
|
||||
Task ||--o| Document : "has 0..1"
|
||||
Document }o--o{ NormArticle : "references n..n"
|
||||
Document ||--|{ DocVersion : "has 1..n"
|
||||
```
|
||||
- A Session can cover zero or more NormArticles
|
||||
- A Session can have one or zero tasks to complete
|
||||
- The Task can be to fill in one or more values in a Form. The values are stored for later retrieval.
|
||||
- The Task can be to upload a Document. The Document is stored for later retrieval.
|
||||
- If a new version of a Document is uploaded, a new DocVersion is created.
|
||||
- A Document is **proof for** one or more NormArticles (ISO 27001 Controls or Chapters)
|
||||
- A NormArticle is **proven by** one or more documents
|
||||
74
AuditGlue/GIS-content-map.md
Normal file
74
AuditGlue/GIS-content-map.md
Normal file
|
|
@ -0,0 +1,74 @@
|
|||
# GIS Content Map
|
||||
|
||||
- **m100: Implementing with ISO27DIY**
|
||||
- [[m100s010-Modules-and-Sessions|m100s010]]: Modules and Sessions
|
||||
- [[m100s020-about-AuditGlue|m100s020]]: About AuditGlue
|
||||
- **m200: About ISO 27001**
|
||||
- [[m200s010-about-ISO27001|m200s010]]: About ISO 27001
|
||||
- **m300: Strategy, Risks and Leadership**
|
||||
- [[m300s010-introduction|m300s010]]: Introduction to Strategy, Risks and Leadership
|
||||
- [[m310s010-organizational-goals|m310s010]]: Organizational Goals
|
||||
- [[m310s020-threat-landscape|m310s020]]: The Threat Landscape
|
||||
- [[m310s030-Identifying-Strategic-Risks|m310s030]]: Identifying Strategic Risks
|
||||
- [[m310s040-qualifying-risks|m310s040]]: Qualifying Risks
|
||||
- [[m310s050-qualifying-impact|m310s050]]: Qualifying Impact
|
||||
- [[m310s060-creating-the-risk-matrix|m310s060]]: Creating the Risk Matrix
|
||||
- [[m310s070-Governance-model|m310s070]]: Governance model
|
||||
- m310s080: Information Security Policy ([[ISO_27001_2022_5.2_MoC Policy|C5.2]])
|
||||
- **m400: Context of the Organization**
|
||||
- [[m400s010-introduction|m400s010]]: Introduction: Why Context Matters
|
||||
- m400s020: Standards, Laws and Regulations ([[ISO_27001_2022_4.2_MoC Understanding the needs and expectations of interested parties|C4.2]], [[ISO_27002_2022_5.31_MoC Legal, statutory, regulatory and contractual requirements|A5.31]], [[ISO_27002_2022_5.34_MoC Privacy and protection of PII|A5.34]])
|
||||
- m400s030: [[iso27diy-git-SYNC!/m300/m300s520-DESTEP-analysis|m300s520]]: **DESTEP analysis** ([[ISO_27001_2022_4.2_MoC Understanding the needs and expectations of interested parties|C4.2]])
|
||||
- m400s040: [[iso27diy-m300s510|m300s510]]: **SWOT analysis** ([[ISO_27001_2022_4.1_MoC Understanding the organization and its context|C4.1]])
|
||||
- m400s050: Stakeholder Analysis ([[ISO_27001_2022_4.2_MoC Understanding the needs and expectations of interested parties|C4.2]])
|
||||
- **m410:Organizational Structures**
|
||||
- [[Introduction for Organizational Structures]]
|
||||
- Organizational processes ([[ISO_27001_2022_4.1_MoC Understanding the organization and its context|C4.1]])
|
||||
- Organization Chart ([[ISO_27001_2022_4.1_MoC Understanding the organization and its context|C4.1]])
|
||||
- Job architecture ([[ISO_27001_2022_4.1_MoC Understanding the organization and its context|C4.1]])
|
||||
- Physical context (sites, buildings, areas) ([[ISO_27002_2022_7.1_MoC Physical security perimeters|A7.1]])
|
||||
- Asset identification ([[ISO_27002_2022_5.9_MoC Inventory of information and other associated assets|A5.9]], [[ISO_27002_2022_5.32_MoC Intellectual property rights|A5.32]])
|
||||
- **420: Planning the Implementation**
|
||||
- [[m300s120-Setting-ISMS-Objectives|m300s120]]: Setting ISMS Objectives
|
||||
- [[iso27diy-git-SYNC!/m300/m300s200-scope|m300s200]]: Setting the Scope
|
||||
- Planning the ISMS implementation ([[ISO_27001_2022_6.1.1_MoC General|C6.1.1]])
|
||||
- **m500: Risks and Measures**
|
||||
- Risk identification ([[ISO_27001_2022_6.1.2_MoC Information security risk assessment|C6.1.2]])
|
||||
- Risk analysis ([[ISO_27001_2022_6.1.2_MoC Information security risk assessment|C6.1.2]])
|
||||
- Data classification ([[ISO_27002_2022_5.12_MoC Classification of information|A5.12]])
|
||||
- Technical vulnerabilities Test ([[ISO_27002_2022_8.8_MoC Management of technical vulnerabilities|A8.8]])
|
||||
- Threat analysis (technical) ([[ISO_27001_2022_6.1.2_MoC Information security risk assessment|C6.1.2]], [[ISO_27002_2022_5.7_MoC Threat intelligence|A5.7]], [[ISO_27002_2022_5.6_MoC Contact with special interest groups|A5.6]])
|
||||
- Controls identification ([[ISO_27001_2022_6.1.3_MoC Information security risk treatment|C6.1.3]])
|
||||
- Roles and responsibilities ([[ISO_27001_2022_5.2_MoC Policy|C5.2]], [[ISO_27001_2022_5.3_MoC Organizational roles, responsibilities and authorities|C5.3]], [[ISO_27002_2022_5.4_MoC Management responsibilities|A5.4]], [[ISO_27002_2022_5.3_MoC Segregation of duties|A5.3]], [[ISO_27002_2022_5.5_MoC Contact with authorities|A5.5]]) – see [[m400-more-governance]]
|
||||
- Planning Controls implementation ([[ISO_27001_2022_8.1_MoC Operational planning and control|C8.1]])
|
||||
- Risk Management ([[ISO_27001_2022_8.1_MoC Operational planning and control|C8.1]], [[ISO_27001_2022_8.2_MoC Information security risk assessment|C8.2]], [[ISO_27001_2022_8.3_MoC Information security risk treatment|C8.3]], [[ISO_27001_2022_10.1_MoC Continual improvement|C10.1]])
|
||||
- Controls implementation ([[ISO_27001_2022_8.3_MoC Information security risk treatment|C8.3]])
|
||||
- **m600: Supporting the ISMS**
|
||||
- Resources ([[ISO_27001_2022_7.1_MoC Resources|C7.1]])
|
||||
- Competencies ([[ISO_27001_2022_7.2_MoC Competence|C7.2]])
|
||||
- Documentation ([[ISO_27002_2022_5.33_MoC Protection of records|A5.33]], [[ISO_27001_2022_7.5.2_MoC Creating and updating|C7.5.2]])
|
||||
- Policies ([[ISO_27002_2022_5.1_MoC Policies for information security|A5.1]])
|
||||
- Review calendar ([[ISO_27002_2022_5.35_MoC Independent review of information security|A5.35]], [[ISO_27001_2022_7.5.2_MoC Creating and updating|C7.5.2]])
|
||||
- Communication and Awareness ([[ISO_27001_2022_7.3_MoC Awareness|C7.3]], [[ISO_27001_2022_7.4_MoC Communication|C7.4]])
|
||||
- **m700: Securing the Business**
|
||||
- m710: Business Continuity
|
||||
- Incident management ([[ISO_27002_2022_5.24_MoC Information security incident management planning and preparation|A5.24]], [[ISO_27002_2022_5.25_MoC Assessment and decision on information security events|A5.25]], [[ISO_27002_2022_5.26_MoC Response to information security incidents|A5.26]], [[ISO_27002_2022_5.27_MoC Learning from information security incidents|A5.27]], [[ISO_27002_2022_5.28_MoC Collection of evidence|A5.28]], [[ISO_27002_2022_5.29_MoC Information security during disruption|A5.29]], [[ISO_27002_2022_5.5_MoC Contact with authorities|A5.5]], [[ISO_27002_2022_5.6_MoC Contact with special interest groups|A5.6]])
|
||||
- Business Impact Analyses ([[ISO_27002_2022_5.29_MoC Information security during disruption|A5.29]], [[ISO_27002_2022_5.30_MoC ICT readiness for business continuity|A5.30]])
|
||||
- Business Continuity Planning ([[ISO_27002_2022_5.29_MoC Information security during disruption|A5.29]], [[ISO_27002_2022_5.30_MoC ICT readiness for business continuity|A5.30]], [[ISO_27002_2022_7.11_MoC Supporting utilities|A7.11]], [[ISO_27002_2022_5.5_MoC Contact with authorities|A5.5]])
|
||||
- m720: People Processes
|
||||
- HR Policies ([[ISO_27002_2022_6.1_MoC Screening|A6.1]], [[ISO_27002_2022_6.2_MoC Terms and conditions of employment|A6.2]], [[ISO_27002_2022_6.3_MoC Information security awareness, education and training|A6.3]], [[ISO_27002_2022_6.4_MoC Disciplinary process|A6.4]], [[ISO_27002_2022_6.5_MoC Responsibilities after termination or change of employment|A6.5]], [[ISO_27002_2022_6.6_MoC Confidentiality or non-disclosure agreements|A6.6]])
|
||||
- User policies ([[ISO_27002_2022_5.10_MoC Acceptable use of information and other associated assets|A5.10]], [[ISO_27002_2022_5.11_MoC Return of assets|A5.11]], [[ISO_27002_2022_5.12_MoC Classification of information|A5.12]], [[ISO_27002_2022_5.13_MoC Labelling of information|A5.13]], [[ISO_27002_2022_5.14_MoC Information transfer|A5.14]], [[ISO_27002_2022_5.37_MoC Documented operating procedures|A5.37]], [[ISO_27002_2022_6.7_MoC Remote working|A6.7]], [[ISO_27002_2022_6.8_MoC Information security event reporting|A6.8]], [[ISO_27002_2022_7.7_MoC Clear desk and clear screen|A7.7]], [[ISO_27002_2022_8.24_MoC Use of cryptography|A8.24]])
|
||||
- Training ([[ISO_27002_2022_6.3_MoC Information security awareness, education and training|A6.3]])
|
||||
- 730: Technology processes
|
||||
- Access Control ([[ISO_27002_2022_5.15_MoC Access control|A5.15]], [[ISO_27002_2022_5.16_MoC Identity management|A5.16]], [[ISO_27002_2022_5.17_MoC Authentication information|A5.17]], [[ISO_27002_2022_5.18_MoC Access rights|A5.18]], [[ISO_27002_2022_8.2_MoC Privileged access rights|A8.2]], [[ISO_27002_2022_8.3_MoC Information access restriction|A8.3]], [[ISO_27002_2022_8.4_MoC Access to source code|A8.4]], [[ISO_27002_2022_8.5_MoC Secure authentication|A8.5]])
|
||||
- Technologies lifecycle ([[ISO_27002_2022_5.8_MoC Information security in project management|A5.8]], [[ISO_27002_2022_5.23_MoC Information security for use of cloud services|A5.23]], [[ISO_27002_2022_8.26_MoC Application security requirements|A8.26]], [[ISO_27002_2022_8.27_MoC Secure system architecture and engineering principles|A8.27]], [[ISO_27002_2022_8.28_MoC Secure coding|A8.28]], [[ISO_27002_2022_8.29_MoC Security testing in development and acceptance|A8.29]], [[ISO_27002_2022_8.30_MoC Outsourced development|A8.30]], [[ISO_27002_2022_8.31_MoC Separation of development, test and production environments|A8.31]], [[ISO_27002_2022_8.32_MoC Change management|A8.32]], [[ISO_27002_2022_8.33_MoC Test information|A8.33]], [[ISO_27002_2022_7.13_MoC Equipment maintenance|A7.13]], [[ISO_27002_2022_7.14_MoC Secure disposal or re-use of equipment|A7.14]], [[ISO_27002_2022_8.6_MoC Capacity management|A8.6]])
|
||||
- Vendor management ([[ISO_27002_2022_5.19_MoC Information security in supplier relationships|A5.19]], [[ISO_27002_2022_5.20_MoC Addressing information security within supplier agreements|A5.20]], [[ISO_27002_2022_5.21_MoC Managing information security in the ICT supply chain|A5.21]], [[ISO_27002_2022_5.22_MoC Monitoring, review and change management of supplier services|A5.22]], [[ISO_27002_2022_5.23_MoC Information security for use of cloud services|A5.23]], [[ISO_27002_2022_8.29_MoC Security testing in development and acceptance|A8.29]])
|
||||
- Device management ([[ISO_27002_2022_7.9_MoC Security of assets off-premises|A7.9]], [[ISO_27002_2022_7.10_MoC Storage media|A7.10]], [[ISO_27002_2022_8.1_MoC User endpoint devices|A8.1]], [[ISO_27002_2022_8.7_MoC Protection against malware|A8.7]])
|
||||
- IT administration ([[ISO_27002_2022_8.7_MoC Protection against malware|A8.7]], [[ISO_27002_2022_8.8_MoC Management of technical vulnerabilities|A8.8]], [[ISO_27002_2022_8.9_MoC Configuration management|A8.9]], [[ISO_27002_2022_8.10_MoC Information deletion|A8.10]], [[ISO_27002_2022_8.11_MoC Data masking|A8.11]], [[ISO_27002_2022_8.12_MoC Data leakage prevention|A8.12]], [[ISO_27002_2022_8.13_MoC Information backup|A8.13]], [[ISO_27002_2022_8.14_MoC Redundancy of information processing facilities|A8.14]], [[ISO_27002_2022_8.15_MoC Logging|A8.15]], [[ISO_27002_2022_8.16_MoC Monitoring activities|A8.16]], [[ISO_27002_2022_8.17_MoC Clock synchronization|A8.17]], [[ISO_27002_2022_8.18_MoC Use of privileged utility programs|A8.18]], [[ISO_27002_2022_8.19_MoC Installation of software on operational systems|A8.19]], [[ISO_27002_2022_8.20_MoC Networks security|A8.20]], [[ISO_27002_2022_8.21_MoC Security of network services|A8.21]], [[ISO_27002_2022_8.22_MoC Segregation of networks|A8.22]], [[ISO_27002_2022_8.23_MoC Web filtering|A8.23]], [[ISO_27002_2022_8.24_MoC Use of cryptography|A8.24]], [[ISO_27002_2022_8.25_MoC Secure development life cycle|A8.25]], [[ISO_27002_2022_8.26_MoC Application security requirements|A8.26]], [[ISO_27002_2022_8.27_MoC Secure system architecture and engineering principles|A8.27]], [[ISO_27002_2022_8.28_MoC Secure coding|A8.28]], [[ISO_27002_2022_8.29_MoC Security testing in development and acceptance|A8.29]], [[ISO_27002_2022_8.30_MoC Outsourced development|A8.30]], [[ISO_27002_2022_8.31_MoC Separation of development, test and production environments|A8.31]], [[ISO_27002_2022_8.32_MoC Change management|A8.32]], [[ISO_27002_2022_8.33_MoC Test information|A8.33]], [[ISO_27002_2022_8.34_MoC Protection of information systems during audit testing|A8.34]], [[ISO_27002_2022_5.6_MoC Contact with special interest groups|A5.6]])
|
||||
- Physical security ([[ISO_27002_2022_7.1_MoC Physical security perimeters|A7.1]], [[ISO_27002_2022_7.2_MoC Physical entry|A7.2]], [[ISO_27002_2022_7.3_MoC Securing offices, rooms and facilities|A7.3]], [[ISO_27002_2022_7.4_MoC Physical security monitoring|A7.4]], [[ISO_27002_2022_7.5_MoC Protecting against physical and environmental threats|A7.5]], [[ISO_27002_2022_7.6_MoC Working in secure areas|A7.6]], [[ISO_27002_2022_7.7_MoC Clear desk and clear screen|A7.7]], [[ISO_27002_2022_7.8_MoC Equipment siting and protection|A7.8]], [[ISO_27002_2022_7.12_MoC Cabling security|A7.12]])
|
||||
- **800: Evaluate and Improve** ([[ISO_27001_2022_9_MoC Performance evaluation|C9]], [[ISO_27001_2022_10_MoC Improvement|C10]])
|
||||
- Audits and Reviews ([[ISO_27001_2022_9.2_MoC Internal audit|C9.2]], [[ISO_27002_2022_5.35_MoC Independent review of information security|A5.35]], [[ISO_27002_2022_5.36_MoC Compliance with policies, rules and standards for information security|A5.36]])
|
||||
- Management Reviews ([[ISO_27001_2022_9.3_MoC Management review|C9.3]])
|
||||
- Planning of Changes ([[ISO_27001_2022_6.3_MoC Planning of changes|C6.3]])
|
||||
- **900: ISO 27001 Audits**
|
||||
- Afwijkingen en Correcties ([[ISO_27001_2022_10.1_MoC Continual improvement|C10.1]])
|
||||
96
AuditGlue/PRD Product Requirements Document for iso27DYI.md
Normal file
96
AuditGlue/PRD Product Requirements Document for iso27DYI.md
Normal file
|
|
@ -0,0 +1,96 @@
|
|||
---
|
||||
tags:
|
||||
- iso27DIY
|
||||
- design
|
||||
---
|
||||
|
||||
# iso27DYI Product Requirements Document (PRD)
|
||||
|
||||
## Product
|
||||
iso27DYI is a web application that offers guided application of the ISO 27001 framework.
|
||||
The purpose of the system is to guide the ‘Client’ in the implementation of an ISO 27001 compliant Information Security Management System (ISMS), and store all the proofs of implementation, so that the Client can pass the ISO 27001 certification audit successfully.
|
||||
|
||||
### Design Guidelines
|
||||
The goal is to build a fully functioning system as described below. We will start with a MVP release and expand and refine on that. The functionality of the MVP release has not been defined yet, neither has the release planning of road map.
|
||||
|
||||
Pointers:
|
||||
- iso27DIY assumes the user has no a priori knowledge of cybersecurity management or ISMS's
|
||||
- iso27DIY guides the client in what to identify, assess and produce, how to do it, and in what order
|
||||
- iso27DYI's guidance will feel like a smartwatch fitness coach, rather than having the user walking down checklists
|
||||
- iso27DIY provides best practice examples and generates compliant content based on the user's input
|
||||
- iso27DYI will help the client with building the necessary capabilities to maintain the ISMS within his own organization
|
||||
- the content will be organized in Modules, with each module consisting of one or more Sessions
|
||||
- the route through the modules is incremental rather that linear (though there are information-dependencies between the modules) – artefacts will be expanded as needed, to facilitate the integration of the ISO 27001 framework in the client's business and management processes (example: incremental RASCI matrix).
|
||||
|
||||
### Client and User
|
||||
The Client is typically an SME, with no dedicated compliance officer and little knowledge of information security management and the ISO 27001 standard.
|
||||
The ‘User’ is the person made responsible for implementing the ISO 27001 standard within the SME. He or she is typically employed as the ‘IT Manager’ or COO.
|
||||
|
||||
### Some words about the ISO 27001 standard
|
||||
The ISO 27001 consists of a prescribed process for managing security risks (the ‘Management System‘), and a number of risk mitigating measures (‘Controls’) that must be implemented to mitigate those risks.
|
||||
According to the ISO 27001, the structure of the management process and its constituent steps, must be described as ‘Policies’.
|
||||
The implementation of the Controls must also be described in Policies.
|
||||
Furthermore, the ISO 27001 requires Proof of implementation. This can take the form of policies, guidelines, manuals, logs, minutes, plans, reports, classifications, etc.
|
||||
There must be evidence of a PDCA cycle being continuously applied to the management system and it’s controls.
|
||||
|
||||
## The iso27DYI system
|
||||
The system contains of three main parts: the Guided Implementation System (GIS) that helps the user to identify, collect and create the Proofs of implementation of the ISMS and its controls, the GRC tool (called ‘AuditGlue’) to store and manage these Proofs, and the Knowledge Base, which supports the identification and generation of Proofs.
|
||||
|
||||
### Guided Implementation System
|
||||
The GIS (Guided Implementation System) takes a User step by step through the implementation of the ISO 27001 management process and its accompanying controls. The implementation is divided into several ‘Modules’, each consisting of several ‘Sessions’.
|
||||
In each Module and Session the User is introduced to the topic at hand through a mixture of videos and texts. The User may be asked to provide information that is relevant to the topic. This happens through a stateful dialogue with a proactive conversational agent. The task of the agent is to fill predefined data slots.
|
||||
The User must have the option to request further explanation, examples either general or specific to the type of Client organization or business process, and support by a Consultant.
|
||||
Support (for implementing the ISMS, not for the usage of the system) is given by an LLM Chat Agent, but can be ‘escalated’ easily into a request to get support by a human consultant.
|
||||
|
||||
Modules and Sessions do not necessarily have to be completed sequentially, but in some cases a Module or Session may be dependent on the information gathered or outcome produced in earlier Modules or Sessions.
|
||||
The progress of the Client and User is visualized in a simple and attractive way, both for progress through Modules and Sessions and for progress towards ‘certification readiness’.
|
||||
|
||||
The Modules, Sessions, and content elements of the GIS will be tagged with identifiers referring to the controls and clauses of the ISO 27001 standard (not by the user but through the management interface, see below).
|
||||
|
||||
The GIS produces artifacts by combining the user’s input with its internal knowledge base. These artifacts may be example Proofs of implementation (as mentioned before), or tailored plans and action lists to construct these Proofs or collect them if they may already be present in the organization.
|
||||
|
||||
All inputs and artifacts are stored in the AuditGlue database.
|
||||
|
||||
The content (text, videos, questionnaires, etc.) that is made available to the user through the GIS are the intellectual property of Thinking Security Works, the company behind iso27DYI. The architecture of the system must prevent this content from being copied or altered by Clients, Users or other parties.
|
||||
|
||||
### AuditGlue
|
||||
AuditGlue is used to store and manage all inputs and artifacts collected or generated through the iso27DIY Guided Implementation System, plus additional artifacts the User deems relevant to the ISO 27001 certification audit.
|
||||
Inputs and artifacts collected or generated through the iso27DIY GIS will be tagged with (roughly) the same identifiers as the Module or Session through which they where collected or generated.
|
||||
Additional artifacts added by the User must be tagged by the user with at least one of the ISO 27001 related identifiers.
|
||||
The user is provided with a mechanism for creating and managing their own tagging system, additional to the ISO 27001 related identifiers provided by the system.
|
||||
The contents of the AuditGlue database may be altered by the user. Version management is implemented for CRUD actions on the content. User may compare different versions of the same documents to show the differences.
|
||||
AuditGlue provides Auditing Views on the contents of the AuditGlue database to support the auditing proces, following the structure of the ISO 27001 standard.
|
||||
|
||||
### The Knowledge Base
|
||||
The user input is used to build a knowledge base about organizational structures, processes, policies, risks and measures related to information security and compliance. This knowledge base is then used to improve the quality of the interaction with users (e.g. asking questions more specific to the context of the user and his type of organization). The knowledge base is not accessible to the User.
|
||||
|
||||
### Management interfaces
|
||||
Management interfaces must be added to the system to allow employees of Thinking Security Works to:
|
||||
- Manage the contents of the GIS
|
||||
- Construct questionnaires and add them as contents to the GIS
|
||||
- Manage system tags and attach them to the contents
|
||||
- Manage Users and allow access to functionality based on their Plan.
|
||||
|
||||
## Functional Diagram
|
||||
|
||||
![[CleanShot 2025-07-17 at 10.45.16.png]]
|
||||
|
||||
## iso72DYI Technical Requirements
|
||||
|
||||
- The system must support multiple Clients, with each client having one or more Users. It is essential that no Client, or any of its Users, ever gets access to another Client’s data. This must be implemented at database level.
|
||||
- The system uses a combination of structured questionnaires, forms, document ingestion and chat agents to acquire user input.
|
||||
- The system uses templates and LLM to generate artifacts. These artifacts consist of text and simple graphics (bitmap images). Output formats are Markdown, DOCX and PDF.
|
||||
- Onboarding must be handled on the iso27diy.com website and should be as frictionless as possible.
|
||||
|
||||
### Leading Principles
|
||||
|
||||
- languages, frameworks, technologies and platforms must be selected to maximize security, portability, maintainability and scaleability (roughly in that order)
|
||||
- current preferences are JavaScript/TypeScript, SQL, JSON/JSONB/JSON Schema, SurveyJS, Postgres
|
||||
- the source code will be available under a, yet to be decided, OSS license
|
||||
- third party code and frameworks that used in the system must be available under OSS licenses that allow commercial use without licensing fees
|
||||
- dependencies on third party code must be kept to a minimum
|
||||
- the number of deployment platforms (data layer, application logic, front end) must be kept to a minimum
|
||||
- user authorization and payment services will be handled through vested service providers
|
||||
- the LLM(s) must be deployed ‘locally’
|
||||
- deployment costs must be acceptable (funds are limited)
|
||||
- architecture, source code and deployment methods must be well documented throughout the project
|
||||
28
AuditGlue/System alternative/Agent Design Intent Card.md
Normal file
28
AuditGlue/System alternative/Agent Design Intent Card.md
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY
|
||||
- dev
|
||||
- llm
|
||||
- agent
|
||||
---
|
||||
[Cognigy course](https://academy.cognigy.com/courses/take/conversation-design-course/lessons/24748613-request-and-reply) Proceed with 4.3
|
||||
|
||||
**Agent Design Intent Card**
|
||||
![[Agent Design Intent Card.png]]
|
||||
|
||||
Notice:
|
||||
- Who = the user
|
||||
- What = the utterance
|
||||
- Intention = get todays menu
|
||||
- Reason = to order food
|
||||
|
||||
A conversation is inherently stateless: it probably won't follow your designed workflow. The user may ignore the bot and continue on his own path.
|
||||
|
||||
**Personality, Persona**
|
||||
A Bot needs a Name and a Character.
|
||||
|
||||
It is a good idea to also have a capability for smalltalk. Users will ask 'how's the weather' or 'how should I prepare for a Zombie attack' or will say 'I love you'
|
||||
[Search Google for repository](https://www.google.com/search?client=safari&rls=en&q=repository+of+intents+and+utterances+for+smalltalk+chatbots&ie=UTF-8&oe=UTF-8)
|
||||
[A collection of sample utterances in various languages](https://github.com/codeforequity-at/botium-utterances).
|
||||
|
||||
Contact Profile: creates persistence, by remembering, for instance, the user's preferences and home address, so the bot doesn't have to ask the same questions again each time.
|
||||
36
AuditGlue/System alternative/Using AI to create policies.md
Normal file
36
AuditGlue/System alternative/Using AI to create policies.md
Normal file
|
|
@ -0,0 +1,36 @@
|
|||
AI-enabled tooling to guide and advise employees in different roles in the organization.
|
||||
|
||||
Examples:
|
||||
|
||||
**Risk analysis**
|
||||
- C-level: high level policies state that we analyse risks and identify mitigating measures when starting a new project
|
||||
- Policy_Agent drafts a context specific policy based on best practices
|
||||
- Project manager:
|
||||
- Risk_Agent provides an overview of the steps to be taken, who to involve in what way (based on stakeholder analyses, creating a RASCI matrix) and guides the project manager through gathering the data. Maybe even plan meetings and send out invites.
|
||||
- Integrate with project management and GRC software
|
||||
|
||||
**Vendor selection**
|
||||
- C-level: high level policies state the security requirements for vendors and applications
|
||||
- Policy_Agent drafts a context specific policy based on best practices
|
||||
- VendorQ_agent creates questionnaires to send out to a selection of vendors
|
||||
- Q_Comparison_agent compares the returned questionnaires with the requirements and creates a table comparing the vendors
|
||||
|
||||
**Data classification**
|
||||
1. questionnaire on how employees would classify different kinds of documents
|
||||
2. a classification matrix is suggested based on the results
|
||||
3. once the policy is established, this serves as a metric on how the perception of different groups of employees differs from the norm
|
||||
4. develop interventions based on these differences
|
||||
|
||||
**Threat analysis**
|
||||
- do a threat analysis, see [[Create a threat analysis chatbot]]
|
||||
|
||||
|
||||
**Policy drafting**
|
||||
|
||||
**Auditing**
|
||||
- a virtual auditor, that interviews you, and identifies areas for improvement
|
||||
|
||||
**Feed the bot**
|
||||
- Blokdyk content
|
||||
- NHC cases
|
||||
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
{
|
||||
"nodes":[
|
||||
{"id":"75c30201fb81b0ec","type":"group","x":-320,"y":140,"width":550,"height":1020,"label":"GIS Guided Implementation System"},
|
||||
{"id":"350b211777e89313","type":"group","x":820,"y":140,"width":560,"height":568,"label":"AuditGlue GRC Tool"},
|
||||
{"id":"a5694aadef906b53","x":820,"y":840,"width":560,"height":320,"type":"group","label":"Knowledge Base"},
|
||||
{"id":"43e5cc1fa3f296af","type":"text","text":"UI/UX","x":190,"y":-510,"width":430,"height":230},
|
||||
{"id":"25aa3aae60de546d","type":"file","file":"📎 Attachments/noun-human-7596266.png","x":-120,"y":-860,"width":235,"height":235},
|
||||
{"id":"f675351f27b4c1ba","type":"file","file":"📎 Attachments/noun-window-104597.png","x":277,"y":-440,"width":117,"height":117,"color":"5"},
|
||||
{"id":"3e88c02ada1829d9","type":"file","file":"📎 Attachments/noun-bot-7868864.png","x":427,"y":-440,"width":117,"height":117,"color":"4"},
|
||||
{"id":"541f3f74ded720a8","type":"text","text":"Example productions and templates","x":-297,"y":655,"width":505,"height":105},
|
||||
{"id":"2d283f7e2af85112","type":"text","text":"Implementation Journey (method)","x":-299,"y":192,"width":505,"height":100},
|
||||
{"id":"336beb2011a0552f","type":"text","text":"Training content","x":-297,"y":350,"width":505,"height":100},
|
||||
{"id":"092a8b1f2b7b6107","type":"text","text":"Library of business processes and structures","x":-301,"y":500,"width":507,"height":105},
|
||||
{"id":"4e7485a3417d5d7a","type":"text","text":"Client organization data","x":-297,"y":813,"width":505,"height":105},
|
||||
{"id":"1663363e7f4bc888","type":"text","text":"ISO 27001 Clauses and Controls\nISO 27002 etc. Guidance","x":-297,"y":980,"width":508,"height":102},
|
||||
{"id":"cb0bca515071c048","type":"text","text":"Document Management","x":840,"y":206,"width":505,"height":105},
|
||||
{"id":"7bf3f2be62b62520","type":"text","text":"Planning","x":840,"y":361,"width":505,"height":105},
|
||||
{"id":"4689e7cb295c69a7","type":"text","text":"Task Management","x":840,"y":518,"width":505,"height":105},
|
||||
{"id":"0c16a220cda9191b","type":"file","file":"📎 Attachments/iso27DYI High level data structure.pdf","x":-301,"y":1620,"width":680,"height":402}
|
||||
],
|
||||
"edges":[
|
||||
{"id":"7255ca95371b2d3c","fromNode":"43e5cc1fa3f296af","fromSide":"top","toNode":"25aa3aae60de546d","toSide":"right","label":"show & teach"},
|
||||
{"id":"52c2a8120e9954a3","fromNode":"25aa3aae60de546d","fromSide":"bottom","toNode":"43e5cc1fa3f296af","toSide":"left","label":"provide information"},
|
||||
{"id":"0172cf6f3059639b","fromNode":"43e5cc1fa3f296af","fromSide":"top","toNode":"25aa3aae60de546d","toSide":"bottom","label":"ask questions"},
|
||||
{"id":"af9db9e573ed4ac8","fromNode":"75c30201fb81b0ec","fromSide":"top","toNode":"43e5cc1fa3f296af","toSide":"bottom","label":"provide guidance\nand examples"},
|
||||
{"id":"b8c13d2facda3ed2","fromNode":"1663363e7f4bc888","fromSide":"left","toNode":"4e7485a3417d5d7a","toSide":"left","label":"determine\ndata slots"},
|
||||
{"id":"4857e13f77b0fa91","fromNode":"75c30201fb81b0ec","fromSide":"right","toNode":"350b211777e89313","toSide":"left","label":"create productions"},
|
||||
{"id":"3d50ce33887c86a9","fromNode":"43e5cc1fa3f296af","fromSide":"bottom","toNode":"350b211777e89313","toSide":"top","label":"provide proofs"},
|
||||
{"id":"942358d1d84bbd49","fromNode":"4e7485a3417d5d7a","fromSide":"right","toNode":"a5694aadef906b53","toSide":"left"},
|
||||
{"id":"dd7ff9142619fc0e","fromNode":"350b211777e89313","fromSide":"bottom","toNode":"a5694aadef906b53","toSide":"top"}
|
||||
]
|
||||
}
|
||||
248
AuditGlue/System alternative/iso27DIY Preferred Stack.md
Normal file
248
AuditGlue/System alternative/iso27DIY Preferred Stack.md
Normal file
|
|
@ -0,0 +1,248 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY
|
||||
- "#stack"
|
||||
- WeWeb
|
||||
- "#SupaBase"
|
||||
---
|
||||
|
||||
# Preferred Low-Code Stack for iso27DIY
|
||||
|
||||
[Perplexity](https://www.perplexity.ai/search/so-far-in-this-conversation-we-KS4D76gkQQi0e7OVClx9qQ)
|
||||
|
||||
**Key Requirements**
|
||||
* Low-code web app development
|
||||
* Avoid vendor/code lock-in
|
||||
* Minimal entry costs for MVP
|
||||
|
||||
### Frontend: WeWeb
|
||||
* **Why:**
|
||||
* Exports clean, customizable Vue.js code, allowing you to fully own and modify your frontend outside the platform~[5](https://www.nocodefinder.com/blog-posts/no-code-tools-export-code)~.
|
||||
* You can self-host, integrate with CI/CD, and deploy anywhere (AWS, Netlify, etc.)~[5](https://www.nocodefinder.com/blog-posts/no-code-tools-export-code)~.
|
||||
* Flexible integration with external backends via APIs.
|
||||
* **Entry Cost:**
|
||||
* Free tier available; paid plans for advanced features, but MVPs can start with minimal cost~[5](https://www.nocodefinder.com/blog-posts/no-code-tools-export-code)~.
|
||||
|
||||
### Backend: Supabase
|
||||
* **Why:**
|
||||
* Supabase is open source, offers a free tier, and provides a scalable PostgreSQL backend with authentication, storage, and real-time features. Supabase offers Edge Functions for business logic.
|
||||
* Airtable is easy for non-developers, but for long-term flexibility, Supabase is preferable.
|
||||
* **Entry Cost:**
|
||||
* Generous free tier for Supabase; Airtable also has a free plan.
|
||||
|
||||
### Integration Layer
|
||||
* Use REST or GraphQL APIs to connect WeWeb (frontend) with Supabase/Airtable (backend).
|
||||
* This loose coupling ensures you can swap out either layer later, minimizing lock-in~[4](https://www.outsystems.com/blog/posts/vendor-lock-in/)~.
|
||||
|
||||
⠀
|
||||
### Why This Stack?
|
||||
* **No Vendor Lock-In:**
|
||||
* Exported frontend code (WeWeb) is fully customizable and can be hosted anywhere~[5](https://www.nocodefinder.com/blog-posts/no-code-tools-export-code)~.
|
||||
* Backend is open source (Supabase) or easily exportable (Airtable data).
|
||||
* Keeping backend and frontend separate via APIs further reduces lock-in risk~[4](https://www.outsystems.com/blog/posts/vendor-lock-in/)~.
|
||||
* **Low Entry Cost:**
|
||||
* Both WeWeb and Supabase offer free tiers suitable for MVPs.
|
||||
* No upfront infrastructure or licensing costs.
|
||||
* **Learning Curve:**
|
||||
* WeWeb’s drag-and-drop interface is beginner-friendly, and Vue.js is widely documented.
|
||||
* Supabase’s dashboard and documentation are accessible for those new to backend development.
|
||||
|
||||
⠀
|
||||
### Alternative Open-Source Low-Code Platform: Appsmith
|
||||
* **Why:**
|
||||
* Open source, can be self-hosted, and is built for internal tools and dashboards~[3](https://www.appsmith.com/blog/low-code-platforms)~.
|
||||
* No vendor lock-in, full access to source code, and usage-based pricing (even free for community edition)~[3](https://www.appsmith.com/blog/low-code-platforms)~.
|
||||
* Integrates with 18+ databases and APIs.
|
||||
* **Best For:**
|
||||
* Internal tools, admin panels, and data-driven apps.
|
||||
|
||||
⠀
|
||||
### Summary Table
|
||||
| **Stack Component** | **Recommended Tool** | **Lock-In Risk** | **Entry Cost** | **Export/Ownership** |
|
||||
|:-:|:-:|:-:|:-:|:-:|
|
||||
| Frontend | WeWeb | Very Low | Free tier | Full code export |
|
||||
| Backend | Supabase | None | Free tier | Open source |
|
||||
| Alternative | Appsmith | None | Free tier | Self-hosted |
|
||||
|
||||
|
||||
### Best Practices to Avoid Lock-In
|
||||
* **Keep your database and business logic outside the low-code platform when possible**~[4](https://www.outsystems.com/blog/posts/vendor-lock-in/)~.
|
||||
* **Use open standards (REST, GraphQL) for integration**.
|
||||
* **Choose platforms that allow code/data export and self-hosting**~[5](https://www.nocodefinder.com/blog-posts/no-code-tools-export-code)~.
|
||||
|
||||
⠀
|
||||
**In summary:**
A stack using WeWeb (frontend, code export), Supabase (backend, open source), and API integration offers the best balance of low entry cost, minimal lock-in, and flexibility for a web app MVP. For internal tools, Appsmith is a strong open-source alternative~[3](https://www.appsmith.com/blog/low-code-platforms)[5](https://www.nocodefinder.com/blog-posts/no-code-tools-export-code)~.
|
||||
1 ~[https://acropolium.com/blog/low-code-mvp/](https://acropolium.com/blog/low-code-mvp/)~
|
||||
2 ~[https://www.mintbit.com/blog/top-7-low-slash-no-code-platforms-for-building-an-mvp/](https://www.mintbit.com/blog/top-7-low-slash-no-code-platforms-for-building-an-mvp/)~
|
||||
3 ~[https://www.appsmith.com/blog/low-code-platforms](https://www.appsmith.com/blog/low-code-platforms)~
|
||||
4 ~[https://www.outsystems.com/blog/posts/vendor-lock-in/](https://www.outsystems.com/blog/posts/vendor-lock-in/)~
|
||||
5 ~[https://www.nocodefinder.com/blog-posts/no-code-tools-export-code](https://www.nocodefinder.com/blog-posts/no-code-tools-export-code)~
|
||||
6 ~[https://impalaintech.com/blog/low-code-platforms-list/](https://impalaintech.com/blog/low-code-platforms-list/)~
|
||||
7 ~[https://www.akveo.com/blog/top-low-code-development-platforms](https://www.akveo.com/blog/top-low-code-development-platforms)~
|
||||
8 ~[https://deployd.co/blog/low-code-vs-traditional-development-cost-comparison-guide](https://deployd.co/blog/low-code-vs-traditional-development-cost-comparison-guide)~
|
||||
9 ~[https://www.linkedin.com/pulse/best-low-code-platforms-mvp-development-amit-prakash-swucf](https://www.linkedin.com/pulse/best-low-code-platforms-mvp-development-amit-prakash-swucf)~
|
||||
10 ~[https://www.appbuilder.dev/blog/vendor-lock-in](https://www.appbuilder.dev/blog/vendor-lock-in)~
|
||||
11 ~[https://www.outsystems.com/application-development/vendor-lock-in-challenges-and-concerns/](https://www.outsystems.com/application-development/vendor-lock-in-challenges-and-concerns/)~
|
||||
12 ~[https://refine.dev/blog/low-code-tools/](https://refine.dev/blog/low-code-tools/)~
|
||||
13 ~[https://rocketdevs.com/blog/low-code-development-platforms](https://rocketdevs.com/blog/low-code-development-platforms)~
|
||||
14 ~[https://impalaintech.com/blog/mvp/low-code-mvp/](https://impalaintech.com/blog/mvp/low-code-mvp/)~
|
||||
15 ~[https://www.netguru.com/blog/bubble-no-code-development](https://www.netguru.com/blog/bubble-no-code-development)~
|
||||
16 ~[https://www.reddit.com/r/SaaS/comments/1fqi03v/what_are_the_best_nocode_tools_to_build_an_mvp/](https://www.reddit.com/r/SaaS/comments/1fqi03v/what_are_the_best_nocode_tools_to_build_an_mvp/)~
|
||||
17 ~[https://www.reddit.com/r/nocode/comments/1fp6857/suggestions_for_a_no_code_platform_that_doesnt/](https://www.reddit.com/r/nocode/comments/1fp6857/suggestions_for_a_no_code_platform_that_doesnt/)~
|
||||
18 ~[https://thectoclub.com/tools/best-low-code-platform/](https://thectoclub.com/tools/best-low-code-platform/)~
|
||||
19 ~[https://www.dhiwise.com/post/how-vibe-coding-compares-to-low-code-platforms](https://www.dhiwise.com/post/how-vibe-coding-compares-to-low-code-platforms)~
|
||||
20 ~[https://techstartups.com/2025/03/01/no-code-and-ai-coding-tools-risks-dangers-limitations-and-hidden-costs-you-need-to-know/](https://techstartups.com/2025/03/01/no-code-and-ai-coding-tools-risks-dangers-limitations-and-hidden-costs-you-need-to-know/)~
|
||||
21 ~[https://vinova.sg/2025/06/03/the-cost-of-developing-an-mvp-budgeting-for-success/](https://vinova.sg/2025/06/03/the-cost-of-developing-an-mvp-budgeting-for-success/)~
|
||||
22 ~[https://www.appbuilder.dev/blog/building-an-mvp-with-low-code](https://www.appbuilder.dev/blog/building-an-mvp-with-low-code)~
|
||||
23 ~[https://budibase.com/blog/open-source-low-code-platforms/](https://budibase.com/blog/open-source-low-code-platforms/)~
|
||||
24 ~[https://www.reddit.com/r/nocode/comments/1j8oemu/the_ultimate_list_to_coding_nocode_and_lowcode/](https://www.reddit.com/r/nocode/comments/1j8oemu/the_ultimate_list_to_coding_nocode_and_lowcode/)~
|
||||
25 ~[https://dev.to/kamal_deeppareek_f5bb5d8/no-codelow-code-tools-for-mvp-development-in-2025-1k3d](https://dev.to/kamal_deeppareek_f5bb5d8/no-codelow-code-tools-for-mvp-development-in-2025-1k3d)~
|
||||
26 ~[https://snappify.com/blog/best-low-code-tools](https://snappify.com/blog/best-low-code-tools)~
|
||||
27 ~[https://deployd.co/low-code-migration-hub/top-5-low-code-migration-strategies-for-enterprise-apps](https://deployd.co/low-code-migration-hub/top-5-low-code-migration-strategies-for-enterprise-apps)~
|
||||
28 ~[https://www.jmix.io/tech-library/low-code-vs-less-code/](https://www.jmix.io/tech-library/low-code-vs-less-code/)~
|
||||
|
||||
WeWeb for the Frontend
|
||||
Supabase for the Database
|
||||
Supabase Edge Functions for business logic
|
||||
Postgres functions for data-centric rules.
|
||||
## Programming the business logic
|
||||
|
||||
With a WeWeb and Supabase stack, you have several options for where to implement business logic, each with different trade-offs for maintainability, scalability, and lock-in:
|
||||
|
||||
### 1. WeWeb Workflows (Frontend)
|
||||
* **What:** Use WeWeb’s built-in visual workflows, conditional logic, and custom JavaScript code blocks to handle simple business rules, UI logic, and API orchestration.
|
||||
* **Best for:** UI-centric logic, simple validations, or workflows tightly coupled to the user interface.
|
||||
* **Limitations:** Puts logic on the client side, which can expose sensitive rules and make maintenance harder as complexity grows~[1](https://community.weweb.io/t/recommendation-for-business-logic-using-supabase/8320)[4](https://www.nocodeassistant.agency/blog/weweb-and-supabase)[5](https://www.weweb.io/integrations/supabase)~.
|
||||
|
||||
⠀
|
||||
### 2. Supabase Database Layer
|
||||
* **What:** Implement business logic in PostgreSQL using database functions, triggers, and stored procedures.
|
||||
* **Best for:** Data validation, calculations, and workflows that must be enforced at the data level (e.g., keeping business rules close to the data, ensuring integrity).
|
||||
* **Pros:**
|
||||
* Logic is centralized, secure, and portable (standard SQL/Postgres).
|
||||
* Reduces vendor lock-in, since you can migrate your database and functions to another Postgres-compatible host if needed~[3](https://www.reddit.com/r/Supabase/comments/1kcm181/how_do_you_get_around_the_lack_of_a_business/)~.
|
||||
* **Cons:**
|
||||
* Writing and maintaining complex logic in SQL/PLpgSQL can be challenging and less flexible than using a general-purpose language~[1](https://community.weweb.io/t/recommendation-for-business-logic-using-supabase/8320)[3](https://www.reddit.com/r/Supabase/comments/1kcm181/how_do_you_get_around_the_lack_of_a_business/)~.
|
||||
|
||||
⠀
|
||||
### 3. Supabase Edge Functions
|
||||
* **What:** Write serverless functions (in TypeScript/JavaScript) that run on Supabase’s infrastructure and are callable via HTTP endpoints.
|
||||
* **Best for:**
|
||||
* More complex business logic, integrating with external APIs, or workflows that shouldn’t run on the client.
|
||||
* Use cases such as checkout flows, custom validations, sending emails, or handling webhooks~[2](https://supabase.com/blog/simplify-backend-with-data-api)~.
|
||||
* **Pros:**
|
||||
* Keeps logic off the client, improves security, and is more maintainable for complex scenarios.
|
||||
* Flexible: you can write logic in a modern language and integrate with any service.
|
||||
* **Cons:**
|
||||
* Adds some operational overhead (deployment, monitoring).
|
||||
* Still somewhat tied to Supabase’s serverless environment, but easier to migrate than pure no-code logic~[1](https://community.weweb.io/t/recommendation-for-business-logic-using-supabase/8320)[2](https://supabase.com/blog/simplify-backend-with-data-api)[3](https://www.reddit.com/r/Supabase/comments/1kcm181/how_do_you_get_around_the_lack_of_a_business/)~.
|
||||
|
||||
⠀
|
||||
### 4. Dedicated Backend (Optional Extra Layer)
|
||||
* **What:** Build a separate backend (e.g., with Node.js, Python, or another stack) to act as a business logic/API layer between WeWeb and Supabase.
|
||||
* **Best for:**
|
||||
* Large projects, highly complex business rules, or when you want maximum portability and control.
|
||||
* **Pros:**
|
||||
* Full flexibility, easy to migrate, and not tied to any one platform.
|
||||
* **Cons:**
|
||||
* Increases development and maintenance effort; may not be necessary for MVPs~[3](https://www.reddit.com/r/Supabase/comments/1kcm181/how_do_you_get_around_the_lack_of_a_business/)~.
|
||||
|
||||
⠀
|
||||
### Best Practice for MVPs
|
||||
* Start with **Supabase Edge Functions** for business logic that shouldn’t be exposed to the client, and use **Postgres functions** for data-centric rules.
|
||||
* Use WeWeb workflows for UI-level logic only.
|
||||
* If your app grows in complexity, you can introduce a dedicated backend later without major refactoring.
|
||||
|
||||
⠀
|
||||
### Summary Table
|
||||
| **Option** | **Language** | **Lock-in Risk** | **Best for** | **Notes** |
|
||||
|:-:|:-:|:-:|:-:|:-:|
|
||||
| WeWeb Workflows | Visual/JS | High | UI logic, simple workflows | Not secure for sensitive logic |
|
||||
| Supabase DB Functions | SQL/PLpgSQL | Low | Data validation, calculations | Portable, but SQL-centric |
|
||||
| Supabase Edge Functions | TypeScript/JS | Moderate | Complex, secure business logic | Good balance for most MVPs |
|
||||
| Dedicated Backend (API) | Any | Very Low | Large/complex projects | Most flexible, most work |
|
||||
|
||||
|
||||
**In conclusion:**
You do not need an extra backend layer for most MVPs. Use Supabase Edge Functions and database functions for business logic, and reserve WeWeb workflows for UI-level tasks. This approach keeps your logic secure, maintainable, and minimizes lock-in while allowing for future migration or scaling~[1](https://community.weweb.io/t/recommendation-for-business-logic-using-supabase/8320)[2](https://supabase.com/blog/simplify-backend-with-data-api)[3](https://www.reddit.com/r/Supabase/comments/1kcm181/how_do_you_get_around_the_lack_of_a_business/)[4](https://www.nocodeassistant.agency/blog/weweb-and-supabase)[5](https://www.weweb.io/integrations/supabase)~.
|
||||
1 ~[https://community.weweb.io/t/recommendation-for-business-logic-using-supabase/8320](https://community.weweb.io/t/recommendation-for-business-logic-using-supabase/8320)~
|
||||
2 ~[https://supabase.com/blog/simplify-backend-with-data-api](https://supabase.com/blog/simplify-backend-with-data-api)~
|
||||
3 ~[https://www.reddit.com/r/Supabase/comments/1kcm181/how_do_you_get_around_the_lack_of_a_business/](https://www.reddit.com/r/Supabase/comments/1kcm181/how_do_you_get_around_the_lack_of_a_business/)~
|
||||
4 ~[https://www.nocodeassistant.agency/blog/weweb-and-supabase](https://www.nocodeassistant.agency/blog/weweb-and-supabase)~
|
||||
5 ~[https://www.weweb.io/integrations/supabase](https://www.weweb.io/integrations/supabase)~
|
||||
6 ~[https://community.weweb.io/t/recommendation-for-business-logic-using-supabase/8320?page=2](https://community.weweb.io/t/recommendation-for-business-logic-using-supabase/8320?page=2)~
|
||||
7 ~[https://community.weweb.io/t/can-supabase-do-the-entire-backend-with-advanced-logic/4181](https://community.weweb.io/t/can-supabase-do-the-entire-backend-with-advanced-logic/4181)~
|
||||
8 ~[https://www.reddit.com/r/Supabase/comments/17c1izo/all_business_logic_within_supabase/](https://www.reddit.com/r/Supabase/comments/17c1izo/all_business_logic_within_supabase/)~
|
||||
9 ~[https://www.youtube.com/watch?v=fZbkLElKuFQ](https://www.youtube.com/watch?v=fZbkLElKuFQ)~
|
||||
10 ~[https://community.weweb.io/t/any-date-for-full-supabase-integration/6050](https://community.weweb.io/t/any-date-for-full-supabase-integration/6050)~
|
||||
|
||||
|
||||
|
||||
## What to familiarize myself with
|
||||
|
||||
**Summary**
|
||||
- WeWeb’s visual tools and
|
||||
- Some JavaScript for the frontend
|
||||
- PostgreSQL for the database
|
||||
- TypeScript/JavaScript for Supabase Edge Functions
|
||||
- Learn how to connect and consume RESTful endpoints
|
||||
|
||||
If you choose WeWeb for the frontend, Supabase for the database, Supabase Edge Functions for business logic, and Postgres functions for data-centric rules, here are the languages and frameworks you should familiarize yourself with:
|
||||
|
||||
### WeWeb (Frontend)
|
||||
* **Visual Development:**
|
||||
* Most UI and workflow logic can be built visually with WeWeb’s drag-and-drop interface~[2](https://www.weweb.io/blog/front-end-design-guide)[8](https://www.weweb.io/blog/no-code-web-app-guide)~.
|
||||
* **JavaScript:**
|
||||
* For custom UI interactions, logic, or integrating with APIs, some knowledge of JavaScript is helpful~[2](https://www.weweb.io/blog/front-end-design-guide)[5](https://unicoconnect.com/careers/weweb)~.
|
||||
* **HTML & CSS (Basics):**
|
||||
* While not strictly required, understanding HTML and CSS will help you troubleshoot, customize, and polish your app’s appearance~[2](https://www.weweb.io/blog/front-end-design-guide)[5](https://unicoconnect.com/careers/weweb)[6](https://www.merixstudio.com/blog/10-skills-need-be-frontend-developer)~.
|
||||
* **RESTful APIs:**
|
||||
* Learn how to connect and consume RESTful endpoints, as WeWeb integrates with external APIs for dynamic data~[2](https://www.weweb.io/blog/front-end-design-guide)[5](https://unicoconnect.com/careers/weweb)~.
|
||||
⠀
|
||||
### Supabase (Database)
|
||||
* **SQL (PostgreSQL dialect):**
|
||||
* For writing queries, managing data, and especially for creating Postgres functions (stored procedures) to handle data-centric business rules~[5](https://unicoconnect.com/careers/weweb)~.
|
||||
* **Database Concepts:**
|
||||
* Understanding tables, relationships, authentication, and permissions in a relational database context~[5](https://unicoconnect.com/careers/weweb)~.
|
||||
|
||||
⠀
|
||||
### Supabase Edge Functions (Business Logic)
|
||||
* **TypeScript/JavaScript:**
|
||||
* Supabase Edge Functions are written in TypeScript or JavaScript, so you’ll need to be comfortable with at least one of these languages to implement backend business logic.
|
||||
|
||||
⠀
|
||||
### General Web Development Skills<!-- {"fold":true} -->
|
||||
* **Version Control (Git):**
|
||||
* Basic familiarity with Git for managing code, especially if you export code from WeWeb or collaborate with others~[3](https://www.reddit.com/r/webdev/comments/10ve6j2/what_skills_should_a_front_end_web_developer_have/)[6](https://www.merixstudio.com/blog/10-skills-need-be-frontend-developer)~.
|
||||
* **Testing & Debugging:**
|
||||
* Ability to test and debug both frontend and backend logic to ensure a robust application~[2](https://www.weweb.io/blog/front-end-design-guide)[5](https://unicoconnect.com/careers/weweb)~.
|
||||
|
||||
⠀
|
||||
### Summary Table
|
||||
| **Layer** | **Language/Frameworks** | **Why Learn It?** |
|
||||
|:-:|:-:|:-:|
|
||||
| WeWeb (Frontend) | Visual builder, JavaScript | UI building, custom logic, API integration |
|
||||
| | HTML, CSS (basics) | Troubleshooting, advanced UI customization |
|
||||
| Supabase (Database) | SQL (Postgres) | Queries, data modeling, Postgres functions |
|
||||
| Supabase Edge Functions | TypeScript/JavaScript | Secure, scalable backend business logic |
|
||||
| General Dev Skills | REST APIs, Git | Integration, code management, team collaboration |
|
||||
|
||||
**In summary:**
You’ll primarily work with WeWeb’s visual tools and some JavaScript for the frontend, SQL/Postgres for the database, and TypeScript/JavaScript for Supabase Edge Functions. This stack minimizes lock-in, is approachable for new developers, and leverages widely-used, well-documented technologies~[2](https://www.weweb.io/blog/front-end-design-guide)[5](https://unicoconnect.com/careers/weweb)~.
|
||||
|
||||
1 ~[https://www.nocodeinstitute.io/nocode-jobs/weweb-developer](https://www.nocodeinstitute.io/nocode-jobs/weweb-developer)~
|
||||
2 ~[https://www.weweb.io/blog/front-end-design-guide](https://www.weweb.io/blog/front-end-design-guide)~
|
||||
3 ~[https://www.reddit.com/r/webdev/comments/10ve6j2/what_skills_should_a_front_end_web_developer_have/](https://www.reddit.com/r/webdev/comments/10ve6j2/what_skills_should_a_front_end_web_developer_have/)~
|
||||
4 ~[https://careerfoundry.com/en/blog/web-development/frontend-developer-skills](https://careerfoundry.com/en/blog/web-development/frontend-developer-skills)~
|
||||
5 ~[https://unicoconnect.com/careers/weweb](https://unicoconnect.com/careers/weweb)~
|
||||
6 ~[https://www.merixstudio.com/blog/10-skills-need-be-frontend-developer](https://www.merixstudio.com/blog/10-skills-need-be-frontend-developer)~
|
||||
7 ~[https://skillcrush.com/blog/skills-to-become-a-front-end-developer/](https://skillcrush.com/blog/skills-to-become-a-front-end-developer/)~
|
||||
8 ~[https://www.weweb.io/blog/no-code-web-app-guide](https://www.weweb.io/blog/no-code-web-app-guide)~
|
||||
|
||||
|
||||
### Learning JavaScript
|
||||
|
||||
* **Mozilla Developer Network (MDN) Web Docs:** Excellent and comprehensive JavaScript guide.
|
||||
* **freeCodeCamp:** Interactive courses that teach you programming fundamentals.
|
||||
* **The Odin Project:** A full-stack curriculum that starts with JavaScript fundamentals.
|
||||
* **Codecademy:** Interactive lessons for foundational concepts.
|
||||
* **"Eloquent JavaScript" by Marijn Haverbeke:** A free online book (more challenging, but very thorough).
|
||||
|
||||
13
AuditGlue/System alternative/iso27DIY UI Canvas.canvas
Normal file
13
AuditGlue/System alternative/iso27DIY UI Canvas.canvas
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
{
|
||||
"nodes":[
|
||||
{"id":"ebb754722fcc96f6","type":"group","x":-620,"y":-480,"width":320,"height":340,"label":"Setting up the ISMS"},
|
||||
{"id":"17fd5c52210c7811","type":"group","x":-220,"y":-480,"width":320,"height":340,"label":"Maintaining the ISMS"},
|
||||
{"id":"718433e9856ea0aa","type":"group","x":-220,"y":-60,"width":320,"height":340,"label":"Support"},
|
||||
{"id":"ab1cb1a22b54522f","type":"group","x":180,"y":-480,"width":320,"height":340,"label":"Auditing the ISMS"}
|
||||
],
|
||||
"edges":[],
|
||||
"metadata":{
|
||||
"version":"1.0-1.0",
|
||||
"frontmatter":{}
|
||||
}
|
||||
}
|
||||
21
AuditGlue/System alternative/iso27DIY UI ideas.md
Normal file
21
AuditGlue/System alternative/iso27DIY UI ideas.md
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
tags:
|
||||
- iso27DIY
|
||||
- design
|
||||
---
|
||||
**Advisera Conformio Guided implementation**
|
||||
https://advisera.com/conformio/
|
||||
|
||||
|
||||
**academy.cognigy.com**
|
||||
Video courses for conversation design
|
||||
![[Cognigy.png|1000]]
|
||||
|
||||
**PECB eLearning**
|
||||
|
||||
![[CleanShot 2025-07-01 at 13.59.22 1.png|1000]]
|
||||
|
||||
**Writing assistant made with Base44**
|
||||
|
||||
![[screenshot 1.png]]
|
||||
|
||||
70
AuditGlue/System alternative/iso27DIY stack deployment.md
Normal file
70
AuditGlue/System alternative/iso27DIY stack deployment.md
Normal file
|
|
@ -0,0 +1,70 @@
|
|||
---
|
||||
tags:
|
||||
- iso27DIY
|
||||
- dev
|
||||
- WeWeb
|
||||
- SupaBase
|
||||
---
|
||||
## WeWeb Frontend Deployment
|
||||
|
||||
**WeWeb handles deployment automatically:**
|
||||
|
||||
- WeWeb applications are deployed directly from their platform
|
||||
- Go to your WeWeb editor and click “Publish”
|
||||
- WeWeb will generate a production URL for your app
|
||||
- You can connect a custom domain through WeWeb’s domain settings
|
||||
- WeWeb uses a global CDN for fast loading times
|
||||
|
||||
**Custom domain setup:**
|
||||
|
||||
- In WeWeb, go to Project Settings > Domain
|
||||
- Add your custom domain and follow their DNS configuration instructions
|
||||
- Update your domain’s DNS records to point to WeWeb’s servers
|
||||
|
||||
## Supabase Backend Deployment
|
||||
|
||||
**Supabase is already cloud-hosted:**
|
||||
|
||||
- Your Supabase project runs on their managed infrastructure
|
||||
- No separate deployment needed for the database and API
|
||||
- Ensure your project is on a paid plan for production use (removes limitations)
|
||||
- Configure Row Level Security (RLS) policies for data protection
|
||||
|
||||
## Integration Configuration
|
||||
|
||||
**Environment variables and API keys:**
|
||||
|
||||
- In WeWeb, configure your Supabase connection in the backend integrations
|
||||
- Use your production Supabase URL and anon key (not the local development ones)
|
||||
- Ensure CORS is properly configured in Supabase for your WeWeb domain
|
||||
- Set up authentication redirects to point to your production WeWeb URL
|
||||
|
||||
**Database preparation:**
|
||||
|
||||
- Run any pending migrations in Supabase
|
||||
- Set up proper indexes for performance
|
||||
- Configure backup policies
|
||||
- Review and tighten security rules
|
||||
|
||||
## Additional Production Considerations
|
||||
|
||||
**Performance optimization:**
|
||||
|
||||
- Enable caching where appropriate in WeWeb
|
||||
- Optimize your Supabase queries and add indexes
|
||||
- Consider setting up database connection pooling if needed
|
||||
|
||||
**Monitoring and maintenance:**
|
||||
|
||||
- Set up Supabase monitoring and alerts
|
||||
- Configure error tracking in WeWeb if available
|
||||
- Plan for regular database maintenance
|
||||
|
||||
**Security checklist:**
|
||||
|
||||
- Review all RLS policies in Supabase
|
||||
- Ensure API keys are properly scoped
|
||||
- Configure proper CORS settings
|
||||
- Set up proper authentication flows
|
||||
|
||||
The main advantage of this stack is that both platforms handle the infrastructure complexity for you - WeWeb manages the frontend hosting and CDN, while Supabase handles the database, API, and authentication infrastructure.
|
||||
|
|
@ -0,0 +1,88 @@
|
|||
---
|
||||
tags:
|
||||
- iso27DIY
|
||||
- architecture
|
||||
- LLMgenerated
|
||||
---
|
||||
# iso27DYI architecture with LLM
|
||||
|
||||
For connecting WeWeb (frontend) and Supabase (backend) with LLM functionality, you have several technology options:
|
||||
- **OpenAI API** or **Anthropic API** directly from your middleware
|
||||
- **Supabase JavaScript client** for database operations
|
||||
- **WeWeb API calls** to your middleware endpoints
|
||||
|
||||
Since WeWeb works well with REST APIs and Supabase has excellent API support, you can build a middleware layer:
|
||||
|
||||
1. **Node.js/Express API** - Create API endpoints that:
|
||||
- Receive requests from WeWeb
|
||||
- Query Supabase for data
|
||||
- Call LLM APIs (OpenAI, Anthropic, etc.)
|
||||
- Return processed responses to WeWeb
|
||||
2. **Supabase Edge Functions** - Use Supabase's serverless functions to:
|
||||
- Handle LLM processing directly within your Supabase environment
|
||||
- Access your database without additional API calls
|
||||
- Deploy TypeScript/JavaScript functions that WeWeb can call
|
||||
3. **Serverless Functions** (Vercel, Netlify, or AWS Lambda):
|
||||
- Deploy functions that orchestrate between WeWeb, Supabase, and LLMs
|
||||
- Good for scaling and keeping costs predictable
|
||||
|
||||
|
||||
The **Supabase Edge Functions** approach is often the most elegant since it keeps everything in your existing Supabase ecosystem and supports TypeScript natively.
|
||||
|
||||
``` typescript
|
||||
// Edge function that:
|
||||
// 1. Receives user input from WeWeb
|
||||
// 2. Queries Supabase database for context
|
||||
// 3. Calls OpenAI/Anthropic API directly
|
||||
// 4. Returns response to WeWeb
|
||||
|
||||
```
|
||||
|
||||
**For your slot-filling + content generation use case:**
|
||||
|
||||
- Direct API calls to LLMs work perfectly
|
||||
- Supabase handles your data needs
|
||||
- WeWeb handles the UI interactions
|
||||
|
||||
## Self-hosting the LLM
|
||||
For self-hosting an LLM with an easy API, here are the simplest options:
|
||||
|
||||
**Ollama (Easiest)**
|
||||
|
||||
- Install Ollama on your server
|
||||
- Pull models like `llama3`, `mistral`, `codellama`
|
||||
- Built-in REST API at `http://localhost:11434`
|
||||
- Simple JSON requests, OpenAI-compatible endpoints
|
||||
- Works great for development and moderate production use
|
||||
|
||||
**vLLM (Best for Production)**
|
||||
|
||||
- High-performance serving with OpenAI-compatible API
|
||||
- Excellent throughput and batching
|
||||
- Simple command: `vllm serve model-name --api-key your-key`
|
||||
- API available at `http://localhost:8000/v1/`
|
||||
|
||||
**Text Generation Inference (TGI)**
|
||||
|
||||
- Hugging Face's production-ready solution
|
||||
- Docker container deployment
|
||||
- OpenAI-compatible API
|
||||
- Good performance optimization
|
||||
|
||||
**For your Supabase setup:**
|
||||
|
||||
1. Deploy Ollama/vLLM on a server (or even locally for development)
|
||||
2. From your Supabase Edge Functions, make HTTP requests to your LLM API
|
||||
3. No need to change your WeWeb → Supabase → LLM flow
|
||||
|
||||
**Quick start with Ollama:**
|
||||
|
||||
```bash
|
||||
# Install and run
|
||||
curl -fsSL https://ollama.ai/install.sh | sh
|
||||
ollama serve
|
||||
ollama pull llama3
|
||||
```
|
||||
|
||||
Then your Edge Functions can call `POST http://your-server:11434/api/generate`
|
||||
|
||||
9
Drafts and Ideas/About/About the Industry.md
Normal file
9
Drafts and Ideas/About/About the Industry.md
Normal file
|
|
@ -0,0 +1,9 @@
|
|||
This next part is about the iso 27001 industry and its actors. Correct the following text so that the proper terms are used. Expand with other actors and their roles if necessary. This is the text:
|
||||
|
||||
- the standards organization develops the standard for a certain domain
|
||||
- the certification bureau checks if the standard is properly implemented within the organization and issues a certificate
|
||||
- Clients, regulatory bodies and other stakeholders of the organization demand the organization to be certified to proof adequate risk control within the domain
|
||||
- the organization implements the standard to get certified
|
||||
- the implementation consultant helps the organization to implement the standard
|
||||
- the internal auditor checks if the standard is properly implemented within the organization
|
||||
- The external auditor works for the certification bureau
|
||||
28
Drafts and Ideas/About/About the flow.md
Normal file
28
Drafts and Ideas/About/About the flow.md
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY/journey
|
||||
- type/explainer
|
||||
---
|
||||
|
||||
## Journey
|
||||
|
||||
We’ll start with analyzing the context of where the ISMS will operate. We’ll look at your organization, it’s structure and processes, important stakeholders and internal and external developments.
|
||||
|
||||
From that we’ll help you identify risks and opportunities, and define risk mitigating measures.
|
||||
|
||||
Together we will create policies, procedures and guidelines, and control implementation plans.
|
||||
|
||||
Gradually, we’ll work towards your first internal audit.
|
||||
|
||||
|
||||
++ increased understanding
|
||||
++ actually improving your security posture
|
||||
We know that we need to get your organization along, so we’ll start with risks and opportunities that matter to your stakeholders.
|
||||
|
||||
## Timeline
|
||||
we will adapt to your pace, but we will actively coach you, like your sports watch would.
|
||||
|
||||
## Interaction model
|
||||
|
||||
|
||||
Work iteratively, you can always come back later
|
||||
0
Drafts and Ideas/About/Essence of the ISMS.md
Normal file
0
Drafts and Ideas/About/Essence of the ISMS.md
Normal file
21
Drafts and Ideas/About/Interactie met de gebruiker.md
Normal file
21
Drafts and Ideas/About/Interactie met de gebruiker.md
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
# Interactie met de gebruiker
|
||||
|
||||
1. Gebruiker kiest een Lesmodule uit menu
|
||||
2. Content wordt getoond. Filmpje, tekst, afbeelding.
|
||||
3. De gebruiker krijgt een ‘taak’. Hij/zij heeft de keuze die nu uit te voeren, of te parkeren in de persoonlijke Takenlijst[^1] (onderdeel van GRC). De taak bevat een verwijzing naar de content, zodat die later weer opgepakt kan worden.
|
||||
4. De taak kan bestaan uit bijv:
|
||||
5. het uploaden van een document
|
||||
6. het invullen van een vragenlijst
|
||||
7. het vullen van een tabel (simpele spreadsheet met rij/kolom totalen bijv)
|
||||
8. Wat de gebruiker toevoegt wordt opgeslagen in de GRC-module
|
||||
9. De input van de gebruiker wordt gebruikt om nieuwe content te genereren, bijv. een beleidsdocument. Dit kan gebeuren met templates, logische regels, of LLM.
|
||||
10. Gegenereerde content wordt ter controle aangeboden aan de gebruiker. Die moet daar wijzigingen in aan kunnen brengen en uiteindelijk de productie akkoord verklaren.
|
||||
11. Na akkoord is er een wijziging in het ‘volwassenheidsniveau’ van het ISMS. Deze komt tot uitdrukking in het ‘Implementatie Dashboard’ (onderdeel van GRC). – kan dynamisch gegenereerd worden
|
||||
|
||||
- [ ] Uitwerken: Er zit onderlinge afhankelijkheid in: soms kun je stap 3 pas nemen als je stap 1 gedaan.
|
||||
- [ ] Volwassenheidsniveaus benoemen.
|
||||
|
||||
|
||||
[^1]: in een latere versie kunnen taken toegewezen worden aan een andere gebruiker.
|
||||
|
||||
|
||||
417
Drafts and Ideas/About/Ocean Sailing Metaphor.md
Normal file
417
Drafts and Ideas/About/Ocean Sailing Metaphor.md
Normal file
|
|
@ -0,0 +1,417 @@
|
|||
# The Merchant Vessel's Voyage: An ISMS Implementation Story
|
||||
|
||||
## **The Premise**
|
||||
|
||||
You're the captain of a merchant trading vessel, transporting valuable cargo across established trade routes. Your mission: deliver precious goods safely to distant ports while building a reputation for reliability and security that will sustain your trading company for years to come.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 1: Charting the Destination** (Setting the Goals)
|
||||
|
||||
Before leaving port, you gather your officers and backers around the navigation table. What defines success for this voyage?
|
||||
|
||||
- **The cargo's safe arrival**: Your hold contains valuable spices, silk, medical herbs, fine instruments - goods that merchants await
|
||||
- **The crew's safe return**: A ship without seasoned sailors is just expensive timber
|
||||
- **Maintaining your reputation**: In the trading world, trust is currency
|
||||
- **Regulatory compliance**: You must satisfy the Harbor Master's requirements and international maritime codes to operate legally
|
||||
- **Sustainable operations**: This isn't a single voyage - you're building a trading enterprise
|
||||
|
||||
You define your **scope**: Which routes will you sail? Which ports are included? What cargo types will you carry?
|
||||
|
||||
Your **security objectives** become clear: confidentiality (cargo manifests and trade secrets), integrity (goods arrive uncontaminated and authentic), availability (reliable delivery schedules).
|
||||
|
||||
You announce these goals to all stakeholders - the ship's owners, the crew, the merchants whose goods you carry.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 2: Reading the Waters** (External Issues)
|
||||
|
||||
Before you can plan your route, you must understand the world through which you'll sail:
|
||||
|
||||
- **Pirate activity**: Which waters are most dangerous? What are their tactics? Are they after cargo, ransom, or the ship itself?
|
||||
- **Weather patterns**: Monsoon seasons, hurricane zones, fog-prone straits
|
||||
- **Geopolitical tensions**: Which nations are at war? Where are trade embargoes? Which flags grant safe passage where?
|
||||
- **Port regulations**: Different harbors have different requirements - quarantine rules, inspection protocols, docking fees
|
||||
- **Competition**: Other trading companies, their routes, their security measures
|
||||
- **Technology changes**: New navigation instruments, faster ships, encrypted communication methods between trading houses
|
||||
- **Economic conditions**: Which goods are in demand? Where are prices best?
|
||||
|
||||
You gather intelligence from:
|
||||
|
||||
- Harbor masters' reports
|
||||
- Returning captains' debriefings
|
||||
- Maritime insurance underwriters
|
||||
- Coastal watchtowers' signals
|
||||
- Trading guild bulletins
|
||||
|
||||
This **external context** shapes every decision you'll make.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 3: Knowing Your Vessel** (Internal Issues, Assets, Strengths & Weaknesses)
|
||||
|
||||
Now you turn your attention inward. What are you working with?
|
||||
|
||||
### **Your Assets to Protect:**
|
||||
|
||||
- **The cargo** (your primary information assets): Spices in the forward hold, medicinal herbs requiring cool storage, sealed letters of credit, navigation charts showing profitable routes
|
||||
- **The ship itself**: Hull integrity, sail condition, water-tightness of hatches
|
||||
- **Your crew**: The navigator's expertise, the surgeon's knowledge, the carpenter's skills
|
||||
- **Your reputation and relationships**: Trust with merchants, favorable insurance rates, preferential port access
|
||||
- **Supporting systems**: The ship's boat (your backup), fresh water supplies, repair materials
|
||||
|
||||
### **Strengths:**
|
||||
|
||||
- Experienced first mate who's sailed these waters for 20 years
|
||||
- Recently reinforced hull
|
||||
- Disciplined crew with low turnover
|
||||
- Strong relationships with key ports
|
||||
|
||||
### **Weaknesses:**
|
||||
|
||||
- The navigator is brilliant but aging, with no clear successor trained
|
||||
- Your encryption methods for sensitive documents are known by former crew who now sail for competitors
|
||||
- The starboard cargo hold has a persistent leak
|
||||
- Only two crew members can operate the new navigational instruments
|
||||
- Your emergency procedures exist mostly in the captain's head
|
||||
|
||||
You conduct a thorough **inventory and assessment**: Who has access to what? Where are critical vulnerabilities? What depends on single points of failure?
|
||||
|
||||
---
|
||||
|
||||
## **Episode 4: Mapping the Dangers** (Risk Assessment)
|
||||
|
||||
With your destination set, external conditions understood, and internal capabilities assessed, you now systematically identify what could go wrong:
|
||||
|
||||
### **Risk Identification:**
|
||||
|
||||
- **Pirates in the Straits of Malacca**: High likelihood, severe impact (loss of cargo and possible crew)
|
||||
- **Storm season in the South China Sea**: Medium likelihood, catastrophic impact
|
||||
- **Crew illness/scurvy**: Medium likelihood, major impact on operations
|
||||
- **Cargo contamination from hold leak**: High likelihood, moderate impact
|
||||
- **Navigator incapacitation**: Low likelihood, severe impact
|
||||
- **Insider threat** (disgruntled crew revealing routes to competitors): Low likelihood, moderate impact
|
||||
- **Port authority seizure** due to paperwork errors: Medium likelihood, major impact
|
||||
- **Fire in the cargo hold**: Low likelihood, catastrophic impact
|
||||
|
||||
### **Risk Analysis:**
|
||||
|
||||
For each risk, you assess:
|
||||
|
||||
- **Likelihood**: Based on historical data (ships lost in these waters), current intelligence (pirate activity reports), ship conditions (that leaky hold)
|
||||
- **Impact**: What happens if this occurs? Loss of cargo value? Crew lives? Ship itself? Reputation damage?
|
||||
- **Existing controls**: What are you already doing? You have fire buckets, a daily inspection routine, experienced crew
|
||||
|
||||
### **Risk Evaluation:**
|
||||
|
||||
You plot these on a risk matrix with your officers. Which risks are acceptable for a merchant vessel? Your risk appetite is moderate - you're not running military secrets that require extreme measures, but you can't afford frequent losses either.
|
||||
|
||||
You prioritize: High likelihood + high impact risks must be addressed immediately. Low likelihood + low impact risks you'll accept.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 5: Plotting the Course** (Risk Treatment - Identifying Measures)
|
||||
|
||||
For each significant risk, you now decide your strategy:
|
||||
|
||||
### **Avoid:**
|
||||
|
||||
- **Don't sail during peak storm season**: Delay departure by three weeks
|
||||
- **Avoid notorious pirate waters entirely**: Take the longer, safer route
|
||||
|
||||
### **Reduce:**
|
||||
|
||||
- **Pirate encounters**: Sail in convoy with other merchants, hire additional armed crew, reinforce the captain's cabin (where valuables are stored), establish communication signals between convoy ships
|
||||
- **Cargo contamination**: Repair the hold leak, use sealed containers, implement daily inspection rounds
|
||||
- **Navigation failure**: Train two junior officers in advanced navigation, maintain duplicate charts stored separately, establish position verification protocols
|
||||
- **Fire**: Implement strict rules about open flames, station fire watch, conduct monthly fire drills, store water barrels strategically
|
||||
|
||||
### **Transfer:**
|
||||
|
||||
- **Cargo loss**: Purchase maritime insurance (though it's expensive and has limitations)
|
||||
- **Crew injury**: Contract with a maritime medical service in major ports
|
||||
|
||||
### **Accept:**
|
||||
|
||||
- **Minor cargo spoilage**: Some loss of spice potency is inevitable over long voyages; build this into pricing
|
||||
- **Wear on sails and rigging**: Routine deterioration; maintain replacement supplies
|
||||
|
||||
You create a **Statement of Applicability** - essentially a ship's security manifest that lists all maritime security controls, which ones you're implementing, which you're not, and why.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 6: The Ship's Standing Orders** (Policies and Procedures)
|
||||
|
||||
Now you formalize how your ship will operate. These aren't just the captain's whims - they're documented protocols that ensure consistency even when you're sleeping:
|
||||
|
||||
### **Access Control Policy** ("Who Goes Where"):
|
||||
|
||||
- **Cargo holds**: Only the quartermaster and captain have keys; entry logged in the ship's book
|
||||
- **Captain's cabin** (sensitive documents): Captain only; first mate has sealed emergency key
|
||||
- **Navigation room**: Navigator and trained officers only
|
||||
- **Critical supplies** (medical stores, emergency rations): Surgeon and quartermaster access; usage logged
|
||||
|
||||
### **Watch Standing Procedures** (Continuous Monitoring):
|
||||
|
||||
- Four-hour watches with clear handoff protocols
|
||||
- What to look for: other ships, weather changes, coastal landmarks
|
||||
- How to sound alarms for different threats
|
||||
- Night signal procedures
|
||||
|
||||
### **Cargo Handling Protocols**:
|
||||
|
||||
- Inspection upon loading (verify against manifest)
|
||||
- Daily hold inspections (check for water, pests, shifting)
|
||||
- Verification before unloading (ensure seals intact)
|
||||
- Chain of custody documentation
|
||||
|
||||
### **Emergency Response Procedures**:
|
||||
|
||||
- **Fire**: Specific roles assigned, equipment locations, communication signals
|
||||
- **Pirate attack**: Battle stations, valuable cargo disposal procedures (if necessary), surrender signals (if absolutely necessary)
|
||||
- **Man overboard**: Stop signals, rescue boat launch, recovery procedures
|
||||
- **Taking on water**: Damage assessment, pumping priorities, emergency port protocols
|
||||
|
||||
### **Navigation Protocols**:
|
||||
|
||||
- Position verification twice daily
|
||||
- Cross-checking between celestial navigation and known landmarks
|
||||
- Backup navigation methods
|
||||
- How to handle disagreement between navigator and captain
|
||||
|
||||
### **Communication Security**:
|
||||
|
||||
- How to encode sensitive messages
|
||||
- Which information can be shared in port
|
||||
- Procedures when crew members depart
|
||||
- How to verify identity of ships claiming to be friendly
|
||||
|
||||
### **Maintenance Standards**:
|
||||
|
||||
- Daily inspections (rigging, hull, pumps)
|
||||
- Weekly maintenance (sail repairs, deck treatment)
|
||||
- Monthly drills (fire, abandon ship, battle)
|
||||
- Equipment testing schedules
|
||||
|
||||
### **Crew Management**:
|
||||
|
||||
- Hiring procedures (background checks with previous captains)
|
||||
- Security training for new crew
|
||||
- Disciplinary procedures
|
||||
- Departure protocols (what they can take, what they must return)
|
||||
|
||||
Each policy answers: **What** must be done, **Why** it matters, **Who** is responsible, **When** and **How** it's done, and **What to do if** something goes wrong.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 7: Casting Off** (Implementation)
|
||||
|
||||
The planning is complete. Now comes the actual voyage - putting your measures into action:
|
||||
|
||||
### **Pre-Departure:**
|
||||
|
||||
- Reinforce the cargo hold (that leak must be fixed)
|
||||
- Install the new secure storage in the captain's cabin
|
||||
- Conduct security training for the crew on the new protocols
|
||||
- Brief all hands on the voyage plan and their roles
|
||||
- Load cargo with new inspection procedures
|
||||
- Verify all equipment is aboard and functional
|
||||
|
||||
### **Underway:**
|
||||
|
||||
- The watch rotation begins according to standing orders
|
||||
- Daily hold inspections reveal the repairs are holding
|
||||
- You drill the crew on emergency procedures weekly
|
||||
- Navigation protocols are followed - the junior officers are learning
|
||||
- Access logs are maintained for all sensitive areas
|
||||
- Incident reports are filed when protocols aren't followed (the cook accessed medical supplies without the surgeon present - why? turns out for a legitimate minor burn, but the procedure needs clarification)
|
||||
|
||||
### **Continuous Adjustment:**
|
||||
|
||||
- Three days out, you receive signals that pirates have been sighted ahead; you adjust course and increase watches
|
||||
- A storm forces you to secure cargo differently than planned - you document the new method
|
||||
- One crew member proves unreliable at watch; they're reassigned and additional training provided to their replacement
|
||||
|
||||
Implementation means **living** the procedures daily, not just having them written down.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 8: Keeping the Ship Supplied** (Resources and Competence)
|
||||
|
||||
A ship doesn't sail on good intentions. Throughout the voyage, you must ensure:
|
||||
|
||||
### **Financial Resources:**
|
||||
|
||||
- Budget for unexpected port fees
|
||||
- Reserve funds for emergency repairs
|
||||
- Insurance premiums
|
||||
- Crew wages (security depends on crew loyalty)
|
||||
|
||||
### **Human Resources:**
|
||||
|
||||
- Adequate crew size for watch rotations
|
||||
- Specialized skills: navigator, surgeon, carpenter, sailmaker
|
||||
- Training time - you can't expect new crew to know complex procedures instantly
|
||||
- Succession planning - you're actively training that junior navigator
|
||||
|
||||
### **Physical Resources:**
|
||||
|
||||
- Spare rigging and sails
|
||||
- Repair materials (timber, pitch, nails)
|
||||
- Security equipment (weapons, locks, sealing wax)
|
||||
- Safety equipment (fire buckets, rescue lines, ship's boat)
|
||||
- Extra supplies beyond minimum (because delays happen)
|
||||
|
||||
### **Knowledge Resources:**
|
||||
|
||||
- Navigation charts (and backups)
|
||||
- Ship's library of maritime procedures
|
||||
- Current intelligence from ports
|
||||
- Documentation of your own procedures and lessons learned
|
||||
|
||||
### **Time:**
|
||||
|
||||
- Adequate voyage timeline (rushing leads to cutting security corners)
|
||||
- Maintenance windows (you must occasionally heave-to for repairs)
|
||||
- Training time during long passages
|
||||
- Rest for crew (exhausted sailors make mistakes)
|
||||
|
||||
You establish **competence requirements**: What must each role know? The first mate must be able to take command. The quartermaster must know cargo handling. All crew must know basic emergency procedures.
|
||||
|
||||
You track **awareness**: Does everyone understand why these security measures matter? They'll follow procedures better if they understand they're protecting their own interests (cargo arrives = they get paid; ship is safe = they live).
|
||||
|
||||
---
|
||||
|
||||
## **Episode 9: The Ship's Log** (Documentation)
|
||||
|
||||
From the moment you leave port, you maintain meticulous records. In the maritime world, if it's not in the log, it didn't happen:
|
||||
|
||||
### **The Master Log:**
|
||||
|
||||
- Daily entries: position, weather, course, significant events
|
||||
- All decisions and why they were made
|
||||
- All incidents and how they were handled
|
||||
- Changes to procedures
|
||||
|
||||
### **Specialized Logs:**
|
||||
|
||||
- **Cargo manifest**: What's aboard, where it's stored, condition checks
|
||||
- **Watch log**: Who was on duty when, what they observed
|
||||
- **Maintenance log**: Repairs, inspections, equipment status
|
||||
- **Incident reports**: Anything unusual, even if minor
|
||||
- **Training records**: Who's been trained on what procedures
|
||||
- **Access logs**: Who entered sensitive areas when
|
||||
|
||||
### **Charts and Plans:**
|
||||
|
||||
- Navigation charts with your actual route (vs. planned)
|
||||
- Cargo stowage plans
|
||||
- Emergency evacuation plans
|
||||
- Crew roster with roles and competencies
|
||||
|
||||
### **Why This Matters:**
|
||||
|
||||
- **Learning**: What worked? What didn't? Your next voyage will be safer
|
||||
- **Accountability**: If something goes wrong, you can trace what happened
|
||||
- **Compliance**: Port authorities and insurers require documentation
|
||||
- **Continuity**: If you're incapacitated, your first mate needs to know everything
|
||||
- **Evidence**: If crew or cargo disputes arise, you have records
|
||||
- **Improvement**: You can't improve what you don't measure
|
||||
|
||||
The ship's log is your organizational memory - it outlasts any single voyage.
|
||||
|
||||
---
|
||||
|
||||
## **Episode 10: Harbor Master's Inspection** (Audit and Review)
|
||||
|
||||
### **Internal Reviews (Ongoing):**
|
||||
|
||||
Throughout the voyage, you conduct regular self-assessments:
|
||||
|
||||
- **Daily bridge briefings**: What happened in the last 24 hours? What's ahead? Are procedures being followed?
|
||||
- **Weekly officer meetings**: Deeper review of security effectiveness, crew morale, equipment status
|
||||
- **Incident reviews**: Whenever something goes wrong (or almost goes wrong), you gather the relevant crew and analyze: What happened? Why? What will we do differently?
|
||||
- **Monthly drills**: Testing emergency procedures and evaluating performance
|
||||
|
||||
### **Port Audits (External):**
|
||||
|
||||
When you reach port, several inspections occur:
|
||||
|
||||
**Harbor Master's Security Inspection:**
|
||||
|
||||
- Are your cargo manifests accurate?
|
||||
- Are dangerous goods properly stored and documented?
|
||||
- Does your crew have proper credentials?
|
||||
- Are your safety and security measures adequate?
|
||||
- Do you meet international maritime security codes?
|
||||
|
||||
The Harbor Master is like your ISO 27001 auditor - they verify you're following established maritime security standards.
|
||||
|
||||
**Cargo Survey:**
|
||||
|
||||
- Merchants' representatives inspect their goods
|
||||
- Verifying seals are intact
|
||||
- Checking condition matches manifest
|
||||
- This proves your controls worked (or reveals where they didn't)
|
||||
|
||||
**Insurance Assessment:**
|
||||
|
||||
- Your insurer may inspect to verify you followed security protocols
|
||||
- This affects future premiums and coverage
|
||||
|
||||
### **Post-Voyage Review (Management Review):**
|
||||
|
||||
After reaching your destination, you conduct a comprehensive review with your officers and the ship's owners:
|
||||
|
||||
**What Worked:**
|
||||
|
||||
- The convoy strategy - no pirate encounters despite sailing through risky waters
|
||||
- Junior navigator training - you now have backup capability
|
||||
- Daily hold inspections caught problems early
|
||||
|
||||
**What Didn't:**
|
||||
|
||||
- The new watch rotation led to gaps in dawn coverage twice
|
||||
- Access logging was inconsistently followed (people got busy)
|
||||
- Fire drill times were too slow - crew needs more practice
|
||||
|
||||
**Metrics Analysis:**
|
||||
|
||||
- Incidents logged: 12 (down from 18 last voyage)
|
||||
- Security procedure compliance: 94% (target was 95%)
|
||||
- Cargo loss: 0.5% (within acceptable range)
|
||||
- On-time arrival: 2 days early (good)
|
||||
- Crew injuries: 1 minor (excellent)
|
||||
|
||||
**Risk Reassessment:**
|
||||
|
||||
- Are the risks you identified still accurate?
|
||||
- Did new risks emerge? (You encountered fog banks that weren't in your initial assessment)
|
||||
- Have external conditions changed? (Political tensions have eased in certain waters)
|
||||
- Are your controls still appropriate?
|
||||
|
||||
**Decisions for Next Voyage:**
|
||||
|
||||
- Adjust watch rotation based on lessons learned
|
||||
- Implement new access control procedure to improve compliance
|
||||
- Conduct more frequent fire drills
|
||||
- Update risk assessment to include fog navigation
|
||||
- Invest in better equipment for certain controls
|
||||
|
||||
### **Continuous Improvement:**
|
||||
|
||||
The voyage doesn't truly end when you reach port. You've learned from this journey, updated your procedures, and you're already preparing for the next departure. The ship's standing orders are now revised - Version 2.0 - incorporating everything you've learned.
|
||||
|
||||
You share lessons with other captains in your trading company. Best practices spread through the fleet.
|
||||
|
||||
**ISO Certification Parallel:** This comprehensive review - with documented evidence from your logs, demonstrated effectiveness of controls, and commitment to continuous improvement - is what convinces the Harbor Master (auditor) to certify your ship as meeting international security standards. The certificate isn't the end goal; it's recognition that you operate a secure, reliable, continuously improving operation.
|
||||
|
||||
---
|
||||
|
||||
## **The Journey Continues**
|
||||
|
||||
Unlike a fortress that, once built, stands static, your merchant vessel is always in motion. The sea changes. Threats evolve. Crews turn over. New ports open. Technology advances.
|
||||
|
||||
Your ISMS is the same - not a project with an end, but an operational discipline. The standing orders (policies) guide daily operations. The log (documentation) captures your organizational memory. The crew (your people) execute with competence and awareness. The inspections (audits) verify effectiveness. And the voyage (your business) continues, safer and more resilient because of the system you've built.
|
||||
|
||||
**The ISO 27001 certificate is your Letter of Marque** - official recognition that your vessel meets the standards required to trade safely in international waters, protecting the valuable cargo (information) entrusted to your care.
|
||||
37
Drafts and Ideas/About/iso27DYI - How this works.md
Normal file
37
Drafts and Ideas/About/iso27DYI - How this works.md
Normal file
|
|
@ -0,0 +1,37 @@
|
|||
# iso27DYI: How this works
|
||||
|
||||
|
||||
## Structure
|
||||
|
||||
We've divided the ISMS implementation into a number of Episodes.
|
||||
|
||||
|
||||
- setting the goals
|
||||
- what's the lay of the land (relevant external issues)
|
||||
- how's our equipe, our assets that need to be protected (internal issues, strengths and weaknesses)
|
||||
- knowing the risks
|
||||
- identifying measures to mitigate the risks
|
||||
- creating the recipes (policies) for resilience in different areas / domains
|
||||
- implementing the risk mitigating measures
|
||||
- ensuring resources to implement and maintain everything
|
||||
- all the while documenting stuff as we go allong
|
||||
- audit and review how we're doing.
|
||||
|
||||
For every element of the ISO 27001 you need to be able to tell the auditor:
|
||||
|
||||
- what your method is for implementing the requirement
|
||||
- how and when you monitor the results of your implementation
|
||||
- how and when you evaluate the results and identify possible improvements
|
||||
- when you are planning to implement these improvements
|
||||
- who's involved and who's responsible for each of these steps.
|
||||
|
||||
In ISO27DIY we deal with this by providing Policy Cards for every Clause and Control of the ISO 27001.
|
||||
|
||||
There's always our Controls Library with everything in Plain English, support by our consultants. When the time is ready, you can plan a preliminiary audit.
|
||||
|
||||
## Principles
|
||||
- work with what you got - keep doing what you do but make it 'compliant'
|
||||
- work iteratively - you can always come back later
|
||||
|
||||
# Metadata
|
||||
- which 'slots' this scene fills
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
# Sources for the Context sessions
|
||||
|
||||
## PECB Lead Auditor Training
|
||||
|
||||
[[PECB 27001 LA S05 E01a - Context of the organization]]
|
||||
|
||||
## Sparks
|
||||
[[The ISMS in its context]]
|
||||
[[Context analysis]]
|
||||
|
||||
## Mark I content
|
||||
[[ISO27DIY Video A.4 Context and Scope - Internal issues]]
|
||||
|
||||
[[ISO27DIY Video A.2 Context and Scope - Stakeholders]]
|
||||
[[ISO27DIY Video A.3 Context and Scope - Regulations and Contracts]]
|
||||
|
||||
## Standard
|
||||
[[ISO_27001_2022_4.1_MoC Understanding the organization and its context]]
|
||||
[[ISO_27001_2022_4.2_MoC Understanding the needs and expectations of interested parties]]
|
||||
[[ISO_27001_2022_4.3_MoC Determining the scope of the information security management system]]
|
||||
[[ISO_27001_2022_4.4_MoC Information security management system]]
|
||||
|
||||
|
||||
## From the 'canvas'
|
||||
Besturingsmodel (4.1)
|
||||
Functiehuis (4.1)
|
||||
Organogram (4.1)
|
||||
Bedrijfsprocessen (4.1)
|
||||
SWOT (4.1)
|
||||
- [[SWOT Analyses template]]
|
||||
DESTEP (4.2)
|
||||
Stakeholder analyse (4.2)
|
||||
Wet- en regelgeving (4.2, A5.31-A5.34)
|
||||
|
||||
## Further research
|
||||
- [ ] Assets?
|
||||
- [ ] Impactbepaling uit [[Dataclassificatie Humankind]]
|
||||
|
||||
|
|
@ -0,0 +1,7 @@
|
|||
# The ISMS in its context
|
||||
|
||||
The primary purpose of the ISMS is to Control information security risks, that may impede on the organization achieving its goals.
|
||||
|
||||
The ISMS does not exist in a vacuum. It interacts with the internal and external context of the organization. 
|
||||
|
||||
An effective ISMS relies on a relationship between / the interplay of organizational goals, its context, threats and risks to the CIA of information, and available resources.
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
---
|
||||
tags:
|
||||
- llm
|
||||
---
|
||||
|
||||
|
||||
[Source](https://www.linkedin.com/posts/mbundgaard_cyber-threat-landscape-analysis-activity-7274406690442149888-Pf-X), retrieved 20-12-24
|
||||
|
||||
Create your own cyber threat analysis GenAI chatbot in 30 minutes.
|
||||
Free of cost and code.
|
||||
|
||||
1) Don't waste your time manually collecting every report from different websites behind forms. Go to [Jacob Wilson](https://www.linkedin.com/in/jacobdjwilson/)'s [github repo](https://github.com/jacobdjwilson/awesome-annual-security-reports/tree/main/) that's updated with all relevant and current reports.
|
||||
2) Don't waste time reading through 20-40 reports that are almost identical. Instead, upload them to [notebooklm.google.com](http://notebooklm.google.com/) and let AI do the heavy lifting.
|
||||
3) Remember to upload/link to your infosec taxonomy. I recommend [VERISframework.org](https://verisframework.org) as it is used by Cyentia Institute and Verizon.
|
||||
4) Don't use any old GPT. Prompt your notebook to get actual references and prevent hallucinations.
|
||||
5) Don't return to the same sources with annotation and manual review. Instead, write and adjust prompts to your specific purposes.
|
||||
|
||||
You now have your very own reliable cyber threat chat bot to help your analyze any problem.
|
||||
|
||||
**Prompt suggestion:**
|
||||
`Context: Doing an annual analysis of the threat landscape surrounding a specific enterprise.`
|
||||
|
||||
`The enterprise is a [region][industry][services] company. It has around [number] employees and annual revenue of [your annual revenue].`
|
||||
|
||||
`Please provide a two-part analysis:`
|
||||
|
||||
1. `A summary of the relevant industry research. The summary must adhere to the [taxonomy] framework. Each section must include examples from the source material and/or statistics such as forecasting or historical changes.`
|
||||
2. `A list of the 5-10 most relevant threat scenarios to be included in a subsequent risk assessment. Provide the scenarios in a table format. The table must include the following columns [column 1], [column 2], [column 3] [etc] and strictly adhere to [taxonomy).`
|
||||
|
||||
For columns I suggest Threat actor, activity and attribute.
|
||||
9
Drafts and Ideas/ISMS/About implementation and proof.md
Normal file
9
Drafts and Ideas/ISMS/About implementation and proof.md
Normal file
|
|
@ -0,0 +1,9 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY
|
||||
- type/explainer
|
||||
---
|
||||
|
||||
The auditor will require proof of the implementation of the ISMS and all it’s individual controls. Proper implementation means a control is risk-based, there’s a policy describing the why and how of it’s implementation, it’s results are monitored or measured, it’s effectiveness is evaluated, and possible improvements to the implementation of the control are identified.
|
||||
|
||||
|
||||
63
Drafts and Ideas/ISMS/About policies controls and risks.md
Normal file
63
Drafts and Ideas/ISMS/About policies controls and risks.md
Normal file
|
|
@ -0,0 +1,63 @@
|
|||
---
|
||||
tags:
|
||||
- iso27001
|
||||
- policy
|
||||
- control
|
||||
- risk
|
||||
---
|
||||
|
||||
|
||||
`Within a ISO 27001 compliant ISMS, is it possible to implement a control without having a policy for that control?`
|
||||
|
||||
`Claude Sonnet 4:`
|
||||
|
||||
In an ISO 27001 compliant ISMS, implementing a control without having a policy for that control is technically possible but not recommended and may create compliance issues.
|
||||
|
||||
Here’s why this creates problems:
|
||||
|
||||
**Policy Requirements**: ISO 27001 requires documented information for information security policies, and Annex A controls often reference the need for established policies. The standard expects that controls should be guided by appropriate policies that define the organization’s approach and requirements.
|
||||
|
||||
**Documentation and Evidence**: During certification audits, auditors will look for evidence that controls are properly governed. A control implemented without supporting policy documentation may be seen as ad hoc or insufficiently managed, potentially leading to non-conformities.
|
||||
|
||||
**Control Effectiveness**: Policies provide the framework for consistent implementation and operation of controls. Without them, you risk:
|
||||
|
||||
- Inconsistent application across the organization
|
||||
- Lack of clear responsibilities and accountabilities
|
||||
- Difficulty in measuring effectiveness
|
||||
- Challenges in maintaining the control over time
|
||||
|
||||
**Best Practice Approach**: The recommended structure is:
|
||||
|
||||
1. **Policy** - High-level statement of intent and requirements
|
||||
2. **Procedures** - Detailed steps for implementation
|
||||
3. **Controls** - Actual security measures and technical implementations
|
||||
4. **Records** - Evidence of operation and effectiveness
|
||||
|
||||
While you might temporarily operate a control without formal policy documentation, you should establish the appropriate policy framework to ensure long-term compliance and effectiveness. This approach aligns with ISO 27001’s emphasis on a systematic, risk-based approach to information security management.
|
||||
|
||||
`Does each control need an associated risk?`
|
||||
|
||||
`Claude Sonnet 4:`
|
||||
|
||||
No, each control does not need an associated risk in an ISO 27001 compliant ISMS. This is a common misconception about how the risk-based approach works.
|
||||
|
||||
**How Risk and Controls Actually Relate:**
|
||||
|
||||
**Risk-Driven Control Selection**: Controls should be selected based on your risk assessment outcomes. You identify risks, evaluate them, and then select controls to treat those risks. However, the relationship is typically many-to-many:
|
||||
|
||||
- One risk may require multiple controls to adequately treat it
|
||||
- One control may address multiple different risks
|
||||
- Some controls may be implemented for compliance or operational reasons beyond specific risk treatment
|
||||
|
||||
(so far, so good …)
|
||||
(if you interpret the following as: specific to your organization, there’s a point somewhere)
|
||||
|
||||
**Baseline Controls**: Organizations often implement baseline security controls (like basic access controls, antivirus, firewalls) that address general security risks rather than being tied to specific identified risks (???). These are considered good security hygiene.
|
||||
|
||||
**Compliance-Driven Controls**: Some controls may be implemented to meet regulatory requirements, contractual obligations, or industry standards, even if they don’t directly correspond to a specific risk you’ve identified in your risk assessment.
|
||||
|
||||
**Control Objectives**: What’s important is that your overall control framework addresses your identified risks and supports your risk treatment decisions. The traceability should be at the risk treatment level, not necessarily at the individual control level.
|
||||
|
||||
**Documentation Expectations**: Your ISMS documentation should demonstrate how your control selection relates to your risk assessment and treatment decisions, but this doesn’t require a one-to-one mapping of every control to a specific risk.
|
||||
|
||||
The key is ensuring your control selection is justified and supports your overall risk management strategy, whether through direct risk treatment, baseline security posture, or compliance requirements.
|
||||
|
|
@ -0,0 +1,17 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY
|
||||
- type/explainer
|
||||
---
|
||||
## About the Statement of Applicability
|
||||
|
||||
In essence, the Statement of Applicability shows the outcome of the risk treatment process ([[ISO_27001_2022_6.1.3_MoC Information security risk treatment|6.1.3a]]). It is usually presented as a table of Annex A controls, together with a short explanation for the selection *or* exclusion of each, and its implementation status.
|
||||
|
||||
This follows directly from [[ISO_27001_2022_6.1.3_MoC Information security risk treatment|Clause 6.1.3d]], that demands that the Statement of Applicability contains:
|
||||
* the controls that are **necessary** to implement the chosen risk treatments, including the rationale for their selection
|
||||
* the **status** of their implementation *("whether the necessary controls are implemented or not")*
|
||||
* the reason for exclusion of any and all other controls from Annex A.
|
||||
|
||||
Though ISO 27002 offers guidelines for the implementation of the controls from Annex, the organization is free in their design. The organization is also free to identify them "from any source", so you could also include controls from for instance XXX or YYY.
|
||||
|
||||
One is generally advised to "Comply or Explain", which means you implement *all* controls from Annex A in some form, or you explain why you don't need to, based on your risk analysis and chosen risk treatment.
|
||||
290
Drafts and Ideas/Measures vs Workability.md
Normal file
290
Drafts and Ideas/Measures vs Workability.md
Normal file
|
|
@ -0,0 +1,290 @@
|
|||
# Measures vs Workability: least privilege, need-to-know
|
||||
|
||||
*Hypothesis: security frameworks promote least privilege and need-to-know for access control, while common data‑classification schemes and real‑world practices frequently result in minimal or inconsistent protective measures until incidents or regulations force stricter controls.*
|
||||
|
||||
What is least privilege, need-to-know. and why is it important?
|
||||
|
||||
- The least privilege principle us defined as giving users only the access they need to perform their job, explicitly to reduce attack surface and limit damage if accounts are compromised.
|
||||
- Excessive permissions and broad access are repeatedly identified as drivers of breaches in cloud environments, where over‑privileged accounts magnify the blast radius of attacks, underscoring how least‑privilege is supposed to be a maximally conservative control principle, not a minimal one.
|
||||
- Security organizations and vendors explicitly promote least‑privilege and need‑to‑know as foundational, proactive principles to minimize risk.
|
||||
|
||||
- Because of cost‑effective management, scalability, and operational efficiency, organizations choose to reserve stronger measures for only the highest sensitivity classes, and apply only baseline controls to the classes.
|
||||
- Implementations often rely on subjective, user‑driven decisions about how to classify information, which is acknowledged as inconsistent and prone to human error; this can lead to sensitive data being misclassified and not receiving appropriate protection until problems are discovered.
|
||||
- Cloud‑security analyses highlight misconfigurations and overly permissive identity and access management as primary causes of data breaches, showing that data is frequently more exposed than its intended classification or policy would suggest, especially when default or “internal” classifications are used with weak enforcement.
|
||||
|
||||
- Studies and policy critiques of government secrecy note pervasive over‑classification of documents, which paradoxically strains controls and leads to mishandling and inconsistent protection because staff cannot realistically maintain high‑grade measures for everything labeled sensitive.
|
||||
- This dynamic supports the idea that classification is often used in a coarse, administrative way, with either over‑broad “classified” labels or broad “internal/public” buckets, and the actual security measures tend to converge on what is minimally workable in practice rather than what the maxim of least privilege would prescribe.
|
||||
|
||||
- data‑classification guidance and breach analyses show that: lower classes are defined to warrant minimal controls, classification is inconsistently applied, and misconfigurations and over‑privileged access remain dominant breach causes—together indicating that classification outcomes often default to minimal measures unless regulatory or incident pressure requires more.
|
||||
|
||||
*Hypothesis: the least privilege tends to be implemented more rigorously and systematically for technical/admin roles than for access to business information.*
|
||||
|
||||
- Modern Privileged Access Management (PAM) practices are explicitly built around least‑privilege: discover all privileged accounts, strip rights down to the minimum, enforce just‑in‑time elevation, and avoid privilege creep.
|
||||
- Vendors and best‑practice guides describe mature patterns such as time‑bound admin elevation, granular role‑based admin roles, session recording, and centralized approval workflows, which directly optimize and monitor admin rights rather than leaving them broadly assigned.
|
||||
|
||||
## Persistent over‑privilege for business data
|
||||
|
||||
- Data‑centric security and DSPM literature repeatedly stresses that over‑privileged access to business data (files, SaaS content, analytics datasets) is widespread, with the majority of granted permissions unused and many of them high‑risk.[2]
|
||||
- Case studies for SaaS data protection highlight “internal overexposure” as a primary issue: collaborative tools make it easy to share information widely, while security teams lack visibility to enforce “need to know” on everyday business documents, HR data, and customer information.[4][2]
|
||||
|
||||
## Indicators that least privilege is better enforced on IT/admin side
|
||||
|
||||
- PAM guidance calls least privilege “fundamental” and prescribes concrete control patterns (role‑based admin levels, just‑in‑time access, automatic revocation, monitoring) that are often implemented as dedicated tools and processes for admin accounts.[6][1][3]
|
||||
- Insider‑threat and privilege‑risk reports emphasize reducing privileged admin accounts and entitlement sprawl as key risk‑reduction goals, showing sustained focus and investment in tightening admin rights, especially in directories and infrastructure platforms.[7][8][9]
|
||||
|
||||
## Business information access lagging behind
|
||||
|
||||
- In contrast, protection of business information often reacts to discovered overexposure: organizations deploy DSPM or SaaS access‑governance tools *because* they find that users can access far more data than they need, not because least‑privilege was consistently applied from the outset.[2][4]
|
||||
- Guidance notes that collaboration platforms “lack capabilities” for teams to “properly protect” sensitive content, forcing retroactive clean‑up of oversharing rather than proactive definition and enforcement of narrow, need‑to‑know scopes.[4]
|
||||
|
||||
## Overall pattern
|
||||
|
||||
- For admin/IT privileges, least privilege is operationalized via specialized tooling, distinct lifecycle processes, and strong monitoring, so the principle is closer to how it is stated in theory.[1][3][5][6]
|
||||
- For access to business information, evidence of entitlement sprawl, unused permissions, and internal overexposure indicates that the effective norm is still broad access with minimal restriction, with least privilege applied selectively or after issues surface.[8][7][2][4]
|
||||
|
||||
Sources
|
||||
[1] 10 Steps to Successful Privileged Access Management https://gotyto.com/thought-leadership/10-steps-to-successful-privileged-access-management/
|
||||
[2] How DSPM Prevents Data Exposure from Overprivileged ... https://www.zscaler.com/blogs/product-insights/how-dspm-helps-prevent-data-exposure-overprivileged-access
|
||||
[3] Privileged access management: Best practices, ... https://heimdalsecurity.com/blog/privileged-access-management-best-practices-implementation-and-tools/
|
||||
[4] Data Access Controls for SaaS | Case Study: Vox Media https://www.docontrol.io/case-studies/vox-media
|
||||
[5] PAM Lifecycle: In-depth Guide to Managing Privileged ... https://www.securden.com/blog/pam-lifecycle.html
|
||||
[6] What is the Principle of Least Privilege? https://www.wallix.com/blogpost/what-is-the-principle-of-least-privilege-and-how-do-you-implement-it-2/
|
||||
[7] The Business Risks of Excessive Privileged Access in ... https://www.lepide.com/blog/risks-of-excessive-privileged-access-in-active-directory/
|
||||
[8] Insider Attacks Climb Sharply in 2024 Data Report https://www.cybersecurity-insiders.com/2024-insider-threat-report/
|
||||
[9] 2024 Insider Threat Report: Key Risks and Cybersecurity ... https://cyberstrategyinstitute.com/2024-insider-threat-report-key-risks-and-cybersecurity-insights/
|
||||
[10] How common is overly strict access to data in your org. https://www.reddit.com/r/datascience/comments/19aedoc/how_common_is_overly_strict_access_to_data_in/
|
||||
|
||||
|
||||
# Google Gemini 1
|
||||
*Hypothesis: “In cybersecurity we have the maxim ‘least privilege, need to know’, which translates as granting people the minimum of access rights needed for their job. Yet with data classification the result is often the minimum of measures, unless absolutely necessary”. Find supporting evidence for this claim.*
|
||||
|
||||
This hypothesis touches on a fundamental tension in cybersecurity: **Access Control** (which is restrictive by nature) versus **Data Classification** (which is often seen as an administrative burden).
|
||||
|
||||
While the principle of "Least Privilege" is a technical cornerstone enforced by systems, "Data Classification" relies heavily on human behavior and business costs, often leading to a "minimum viable effort" approach.
|
||||
|
||||
---
|
||||
|
||||
## 1. The Enforcement Gap
|
||||
|
||||
The primary reason for this discrepancy is how these two concepts are implemented.
|
||||
|
||||
- **Least Privilege (Restrictive):** This is often hard-coded into Identity and Access Management (IAM) systems. It is "fail-secure," meaning if you don't have the permission, you simply cannot perform the action.
|
||||
|
||||
- **Data Classification (Permissive):** Classification is often manual or semi-automated. Because over-classifying data (e.g., marking everything "Top Secret") creates massive operational friction and storage costs, organizations default to the lowest classification level unless a specific regulatory trigger (like PCI-DSS or GDPR) forces their hand.
|
||||
|
||||
|
||||
## 2. Supporting Evidence for "Minimum Measures"
|
||||
|
||||
### The "Default to Public" Bias
|
||||
|
||||
Studies in organizational behavior suggest that employees view classification as a secondary task. According to various industry reports (such as the _Verizon Data Breach Investigations Report_), a significant portion of data breaches occur because sensitive data was stored in an unclassified or "General" folder. Organizations often apply the **minimum measure** of "Internal Use Only" to avoid the rigorous encryption and audit requirements of "Restricted" or "Confidential" tiers.
|
||||
|
||||
### Cost and Complexity of Controls
|
||||
|
||||
Data classification isn't just a label; it’s a commitment to a set of controls.
|
||||
|
||||
- **Storage Costs:** Highly classified data often requires expensive, redundant, and encrypted storage.
|
||||
|
||||
- Usability: Measures like Digital Rights Management (DRM) or strict Data Loss Prevention (DLP) rules can break workflows.
|
||||
|
||||
To maintain productivity, leadership often signs off on the "minimum necessary" classification to keep the business moving, effectively prioritizing availability over confidentiality.
|
||||
|
||||
|
||||
### Compliance-Driven Security (The "Checklist" Mentality)
|
||||
|
||||
Many organizations treat data classification as a compliance checkbox rather than a security strategy.
|
||||
|
||||
- **Evidence:** In frameworks like ISO 27001, organizations are required to define classification levels. However, they often define them so broadly that the vast majority of data falls into a category with minimal protection.
|
||||
|
||||
- **The Result:** If a regulation doesn't specifically demand a measure (like per-file encryption), it is rarely implemented.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 3. Comparing the Two Mindsets
|
||||
|
||||
|**Feature**|**Least Privilege (Access)**|**Data Classification (Protection)**|
|
||||
|---|---|---|
|
||||
|**Primary Goal**|Minimize the attack surface.|Categorize for handling.|
|
||||
|**Default State**|Deny All.|Open/General (often).|
|
||||
|**Friction Level**|High (but expected).|High (and often resisted).|
|
||||
|**Implementation**|Technical/Automated.|Policy/Behavioral.|
|
||||
|
||||
---
|
||||
|
||||
## Summary of the Tension
|
||||
|
||||
The maxim "Least Privilege" is a **shield**, while Data Classification is often treated as a **filing system**. Because the latter requires constant manual effort and incurs operational costs, the "minimum of measures" becomes the path of least resistance. This creates a "security debt" where access is tight, but the data itself is poorly protected once an authorized user (or a compromised account) handles it.
|
||||
|
||||
# Google Gemini 2
|
||||
|
||||
Yes, your observation is supported by a significant "implementation gap" in modern cybersecurity. In short: **IT resources are protected by a "Shield" (Hard Enforcement), while Business Information is protected by a "Policy" (Soft Enforcement).**
|
||||
|
||||
The evidence for why "least privilege" is better implemented for IT admins compared to business data access boils down to three core drivers:
|
||||
|
||||
---
|
||||
|
||||
## 1. Technical Tooling: The PAM vs. Governance Gap
|
||||
|
||||
The industry has developed highly mature, automated tools for IT administration that do not yet have a seamless equivalent for everyday business data.
|
||||
|
||||
- **For IT Admins:** Tools like **Privileged Access Management (PAM)** (e.g., CyberArk, BeyondTrust) enable **Just-in-Time (JIT)** access. An IT admin has zero standing privileges; they must request "Domain Admin" rights for a specific window (e.g., 2 hours). Once the task is done, the system automatically strips the rights.
|
||||
|
||||
- **For Business Users:** Access to "Financial Projections" or "HR Records" usually relies on **Identity Governance and Administration (IGA)**. These are often static. Once a user is added to a "Finance" group, they stay there until a manual (and often "rubber-stamped") quarterly review happens. There is rarely a JIT system for reading a spreadsheet.
|
||||
|
||||
|
||||
## 2. Risk Clarity: "Systemic" vs. "Incremental" Damage
|
||||
|
||||
Cybersecurity teams prioritize what they can clearly quantify.
|
||||
|
||||
- **IT Infrastructure (Systemic Risk):** A compromised admin account is an "extinction-level event" (e.g., ransomware deployment across the entire network). Because the **Blast Radius** is so high, management is willing to accept the friction of least privilege.
|
||||
|
||||
- **Business Data (Incremental Risk):** The theft of a single client list is damaging but rarely crashes the company's entire infrastructure. Because the damage feels "contained," organizations are less willing to slow down business operations with strict access hurdles.
|
||||
|
||||
|
||||
## 3. The "Productivity Tax" and Culture
|
||||
|
||||
IT staff are culturally conditioned to work within restrictive environments (using "Service Accounts" or "Sudo"). Business users, however, often view security hurdles as an impediment to their primary job.
|
||||
|
||||
- **The Help Desk Effect:** Research shows that when IT restricts a business user’s access to a folder they _might_ need, the user calls the Help Desk immediately. To reduce ticket volume, Help Desks often default to "over-provisioning"—granting broader access than necessary just to ensure the user doesn't call back.
|
||||
|
||||
- **Admin Consistency:** IT admins are few in number and their roles are clearly defined (Network Admin, Database Admin). Business roles are fluid and "cross-functional," making it technically difficult to define what "least privilege" even looks like for a Marketing Manager who also assists with Product and Sales.
|
||||
|
||||
|
||||
---
|
||||
|
||||
### Comparison Summary: The Implementation Gap
|
||||
|
||||
|**Feature**|**IT Admin Privileges**|**Business Data Access**|
|
||||
|---|---|---|
|
||||
|**Control Model**|**Zero Standing Privilege** (ZSP)|**Persistent Access** (Group-based)|
|
||||
|**Enforcement**|Automated/Technical|Manual/Policy-based|
|
||||
|**Auditability**|High (Session recording common)|Low (Hard to see who read what)|
|
||||
|**Implementation**|**Mature** (PAM is a standard)|**Emerging** (Data Governance is often messy)|
|
||||
|
||||
---
|
||||
|
||||
## Conclusion
|
||||
|
||||
Your hypothesis is correct: "Least privilege" is a technical reality for IT admins because we have the tools to automate it. For business data, it remains an aspirational goal because it requires human judgment and manual classification—both of which naturally trend toward the "minimum of measures" to keep the business moving.
|
||||
|
||||
**Would you like me to look into "Zero Trust Data Access" (ZTDA) technologies, which are the industry's attempt to bring IT-level strictness to business document access?**
|
||||
|
||||
|
||||
---
|
||||
|
||||
Hypothesis: *Can we also see the ‘least privilege’ principle being better implemented when it comes to various levels of admin privileges for IT resources, vs access to business information?*
|
||||
|
||||
---
|
||||
|
||||
Yes, there is significant evidence that the **Least Privilege** principle is much more rigorously applied to **IT infrastructure and admin rights** than to **business data**.
|
||||
|
||||
The reason for this "implementation gap" is the difference between technical governance (managing _systems_) and cultural governance (managing _information_).
|
||||
|
||||
---
|
||||
|
||||
## 1. Technical Enforcement vs. Behavioral Expectation
|
||||
|
||||
IT resources are managed through **Privileged Access Management (PAM)** and **Identity & Access Management (IAM)** tools. These systems allow for "hard" enforcement.
|
||||
|
||||
- **IT Infrastructure (The Admin Level):** Removing "Local Admin" rights from laptops or "Domain Admin" from IT staff is a common, measurable goal. Tools can automatically rotate passwords and provide **Just-in-Time (JIT)** access. If an admin needs to change a server setting, they request access for one hour, and it is automatically revoked.
|
||||
|
||||
- **Business Information (The Data Level):** Access to "Financial Reports" or "Project Strategy" is much "fuzzier." Because business roles are fluid, managers often grant broad access ("Just give them access to the whole folder") to avoid slowing down work. There is rarely a JIT system for "reading a PDF."
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 2. The "Blast Radius" Metric
|
||||
|
||||
Security teams prioritize IT admin rights because the **Blast Radius** is objective and catastrophic.
|
||||
|
||||
- **IT Admin:** A compromised "Superuser" can take down the entire network, install ransomware globally, or delete backups. The risk is **Systemic**.
|
||||
|
||||
- **Business Data:** A compromised "Sales Manager" can steal customer lists. While damaging, it is rarely "existential" for the IT infrastructure. Therefore, companies invest heavily in PAM tools for admins while leaving business data in broad, "Internal Use Only" buckets.
|
||||
|
||||
|
||||
### Comparison: Admin vs. Business Data
|
||||
|
||||
|**Feature**|**IT Admin Privileges**|**Business Information Access**|
|
||||
|---|---|---|
|
||||
|**Control Tool**|PAM (e.g., CyberArk, BeyondTrust)|Shared Drives, SharePoint, Teams|
|
||||
|**Enforcement**|Hard (Access is blocked by default)|Soft (Access is often granted by peers/managers)|
|
||||
|**Audit Frequency**|High (Often daily/weekly)|Low (Quarterly "Access Reviews" often rubber-stamped)|
|
||||
|**Philosophy**|**Least Privilege** (Zero by default)|**Need to Know** (Often "Assume they need it")|
|
||||
|
||||
---
|
||||
|
||||
## 3. The "Rubber Stamp" Phenomenon
|
||||
|
||||
Evidence for your claim can be found in User Access Reviews (UAR).
|
||||
|
||||
In technical environments, engineers are used to justified access requests. However, in business departments, access reviews are often seen as an administrative chore.
|
||||
|
||||
> **Research Insight:** Studies show that business managers have a high rate of "Access Creep." When asked to review who has access to a folder, they often approve everyone "just in case" to avoid interrupting someone's work. In contrast, IT departments use automated scripts to prune unused admin accounts because an unused admin account is a massive, clear liability.
|
||||
|
||||
---
|
||||
|
||||
## 4. Supporting Your Claim
|
||||
|
||||
Your original hypothesis is supported by the fact that **Data Classification** (the "minimum measures" problem) is the weakest link. Even if an IT admin has "Least Privilege" over the server, if the data on that server is classified as "General" when it should be "Restricted," the technical controls on the admin are irrelevant—the data is already under-protected.
|
||||
|
||||
---
|
||||
|
||||
*Do we see a difference between implementation of access restrictions between document storage and SaaS solutions?*
|
||||
|
||||
---
|
||||
|
||||
There is a profound difference between the two, primarily driven by a shift from **"Centralized Governance"** to **"User-Led Decentralization."**
|
||||
|
||||
While traditional document storage often feels like a "Fortress," SaaS solutions frequently resemble a "Wild West." This shift reinforces your hypothesis: when the burden of security moves from the system (IT) to the user (Business), the "minimum of measures" usually wins.
|
||||
|
||||
---
|
||||
|
||||
## 1. Document Storage: The "Fortress" Model
|
||||
|
||||
In traditional environments (On-premise file shares, SharePoint), access is managed via **Hierarchical Permissions**.
|
||||
|
||||
- **Implementation:** IT or "Data Owners" set permissions at the folder level. These are often static and reviewed during annual audits.
|
||||
|
||||
- **The Least Privilege Reality:** It is easier to enforce here because the structure is rigid. If you aren't in the "Finance" group, you can't enter the "Finance" folder.
|
||||
|
||||
- **The Classification Fail:** Even in this rigid system, your "minimum measures" claim holds true: people often dump sensitive files into "General" folders simply because they don't want to deal with the permission request process to get into a restricted one.
|
||||
|
||||
|
||||
## 2. SaaS Solutions: The "Liquid" Model
|
||||
|
||||
SaaS (Google Drive, Slack, Salesforce, Figma) introduces **Object-Level Sharing**, which shatters the traditional perimeter.
|
||||
|
||||
- **The "Link-Sharing" Trap:** SaaS thrives on speed. Most SaaS apps allow users to "Share with anyone with the link."1 This is the ultimate "minimum measure"—it bypasses least privilege entirely to ensure productivity isn't hindered.
|
||||
|
||||
- **SaaS Sprawl:** Because SaaS is decentralized, IT often loses visibility.2 Research indicates that up to **90% of SaaS applications in an enterprise are unmanaged** (Shadow IT).3 In these cases, there is _no_ least privilege; there is only "User Discretion."
|
||||
|
||||
- **Identity vs. Access:** In SaaS, identity is often managed (SSO), but _what_ that identity can do inside the app is often left to the user. A user might be granted "Editor" rights to a whole workspace because the "Viewer" role was too restrictive for a five-minute task, and the permission is never revoked.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 3. Comparison of Implementation Gaps
|
||||
|
||||
|**Feature**|**Document Storage (Legacy)**|**SaaS Solutions (Modern)**|
|
||||
|---|---|---|
|
||||
|**Control Unit**|The Folder (Group-based)|The File/Object (User-based)|
|
||||
|**Primary Risk**|"Access Creep" (Too many folders)|"Oversharing" (Public links/Guest access)|
|
||||
|**Visibility**|High (IT can see the whole tree)|Low (Siloed within individual apps)|
|
||||
|**Least Privilege**|Enforced by IT Admins|Delegated to end-users|
|
||||
|**Classification**|Often ignored (Manual labeling)|Frequently non-existent|
|
||||
|
||||
---
|
||||
|
||||
## 4. Why SaaS Validates Your Hypothesis
|
||||
|
||||
SaaS environments prove your point that we default to the "minimum of measures" for the sake of necessity.
|
||||
|
||||
- **The Productivity Tax:** Implementing true "Least Privilege" in a tool like Slack or Teams (e.g., private channels for everything) is so administratively heavy that teams almost always opt for "Public Channels" by default.
|
||||
|
||||
- **The "Shadow" Effect:** When security measures (like classification or restricted access) become too burdensome in a corporate document store, users migrate data to a personal SaaS account (Dropbox/Gmail) to "just get the job done."
|
||||
|
||||
|
||||
> **Key takeaway:** In SaaS, the "Least Privilege" principle is often sacrificed at the altar of **collaboration speed**.
|
||||
|
||||
|
||||
36
Drafts and Ideas/Metadata in YAML.md
Normal file
36
Drafts and Ideas/Metadata in YAML.md
Normal file
|
|
@ -0,0 +1,36 @@
|
|||
# Metadata in YAML
|
||||
|
||||
## For session files
|
||||
|
||||
| Required | Key | Value | Example | Explanation |
|
||||
| ------------ | -------------- | --------------- | ---------------------------- | ------------------------------------------------------------------------------------------------------ |
|
||||
| * | id | string | m123s456 | 123 denotes Module, 456 denotes Session |
|
||||
| * | module | string | 123 | Module id |
|
||||
| * | session | string | 456 | Session id |
|
||||
| * | title | string | Establishing Objectives | Module title as displayed on screen |
|
||||
| | implements | list of strings | ISO27001:2022:C.6.2 | Reference to norm articles; C is Clause and A is Annex (i.e. control) |
|
||||
| | feeds_into | list of strings | m200s030 | Outcomes of the current session are inputs for the denoted session - not processed, for oversight only |
|
||||
| | depends_on | list of strings | m100s010 | Module+Session id from which the outcomes are input for the current session |
|
||||
| * | related_form | *tbd* | *tbd* | Denotes Formdown file for session |
|
||||
| | related_assets | list of strings | m123s456-objectives-examples | Denotes related asset-files |
|
||||
|
||||
- Key-value pairs may be included in any order, as long as the required keys are there
|
||||
- Additional key-value pairs can be added as you see fit – AuditGlue will ignore them
|
||||
- Filenames for content and assets can be chosen freely: AuditGlue uses the metatada to weave it's magic
|
||||
|
||||
|
||||
### Source example (for copy-paste)
|
||||
---
|
||||
id: m300s100
|
||||
module: 300
|
||||
session: 100
|
||||
title: Establishing Objectives
|
||||
implements:
|
||||
- ISO27001:2022:C.6.2
|
||||
feeds_into:
|
||||
depends_on:
|
||||
related_form:
|
||||
related_assets:
|
||||
- m300s100-objectives-examples
|
||||
---
|
||||
|
||||
18
Drafts and Ideas/Most Challenging Clauses in ISO 27001.md
Normal file
18
Drafts and Ideas/Most Challenging Clauses in ISO 27001.md
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
# Most Challenging Clauses in ISO 27001
|
||||
|
||||
Professionals cite difficulties with:
|
||||
|
||||
* **Clause 4: Context of the Organization**
|
||||
* defining the organization’s boundaries
|
||||
* determining relevant interested parties
|
||||
* documenting the complex interrelationships among processes required by Clause 4.4. Show how processes interact and link to business needs
|
||||
* **Clause 6: Planning (Risk Assessment and Objectives)**
|
||||
* identifying, evaluating, and treating risks
|
||||
* choosing a risk methodology
|
||||
* ensuring risk assessments meet auditor expectations
|
||||
* **Clause 9: Performance Evaluation**
|
||||
* Monitoring, measurement, analysis, and evaluation (especially Clause 9.1), esp. establish meaningful objectives, gather relevant metrics, and provide evidence of improvement.
|
||||
* **Clause 10: Improvement (Nonconformity and Corrective Action)**
|
||||
* a systematic approach to identifying, investigating, and tracking corrective actions.
|
||||
* **Annex A Control Mapping and Statement of Applicability**
|
||||
* The breadth of required controls and the need to justify inclusions/exclusions create confusion
|
||||
|
|
@ -0,0 +1,87 @@
|
|||
# Policy Card Example for Access to Software Applications
|
||||
|
||||
- PolicyTitle: "Application access policy "
|
||||
- RelevantStandardArticles: <tags> ISO27001:2022:A.5.15, ISO27001:2022:A.5.18
|
||||
- VersionControl
|
||||
- VersionNumber: 3.14
|
||||
- VersionDate: 15-12-2024
|
||||
- DocumentOwner: "Alex Hanover"
|
||||
- ApprovedBy: "Marian Faithful" <signature>
|
||||
- ApprovedDate: 08-01-2025
|
||||
- NextReview: 15-12-2025
|
||||
- Purpose
|
||||
- Goal (in terms of risk mitigation): "To protect classified data from unauthorized access"
|
||||
- Scope : "All applications in use within the organization" // E.g. organization as a whole vs. topic-specific: certain business activities, organizational units, or the implementation of specific controls. Also define Exemptions and Exceptions.
|
||||
- RisksMitigated: "Unauthorized access to classified data" // outcome from the Risk Analysis activity
|
||||
- ControlsImplemented: <tags> ISO27001:2022:5.15, ISO27001:2022:5.18
|
||||
- Method
|
||||
- Implementation ('How it's done'): "To mitigate the risk of X, controls A, B and C will be implemented on asset Y by Responsible Z. The effectiveness will be measured through P and will be evaluated by Q according to method R, following planning S."
|
||||
- Metrics: "Number of users with unjustly granted access to each application, compared to the necessary access following from the Job Framework " (to establish effectiveness)
|
||||
- Measurement: "The number of users with unjust access will be determined each quarter by HR, based on the current access matrix delivered by IT" // How, When, and By Whom
|
||||
- Evaluation: "The effectiveness of the control will be evaluated quarterly by the Compliance Officer in a meeting with HR and IT" // How, When, and By Whom
|
||||
- Reviews and Changes
|
||||
- Review: "This policy will be reviewed yearly or if relevant and significant changes occur in the organization, in a meeting with the CISO, COO and Compliance Officer"
|
||||
- Changes: "Changes to this policy will be prepared by the policy o"
|
||||
- Responsibilities (for implementation and review)
|
||||
- PolicyWriting: "IT consultant"
|
||||
- PolicyApproval: "CISO"
|
||||
- Implementation: "IT Administration dept."
|
||||
- Documentation
|
||||
- PolicyDocuments: <pointers>
|
||||
- ProcedureDescriptions: <pointers>
|
||||
- MeasurementReports: <pointers>
|
||||
- EvaluationReports: <pointers>
|
||||
|
||||
## In JSON format
|
||||
|
||||
```
|
||||
JSON
|
||||
{
|
||||
"PolicyTitle": "Application access policy",
|
||||
"RelevantStandardArticles": [
|
||||
"ISO27001:2022:5.15",
|
||||
"ISO27001:2022:5.18"
|
||||
],
|
||||
"VersionControl": {
|
||||
"VersionNumber": "3.14",
|
||||
"VersionDate": "2024-12-15",
|
||||
"DocumentOwner": "Alex Hanover",
|
||||
"ApprovedBy": "Marian Faithful",
|
||||
"ApprovedDate": "2025-01-08",
|
||||
"NextReview": "2025-12-15"
|
||||
},
|
||||
"Purpose": {
|
||||
"Goal": "To protect classified data from unauthorized access",
|
||||
"Scope": "All applications in use within the organization",
|
||||
"RisksMitigated": "Unauthorized access to classified data",
|
||||
"ControlsImplemented": [
|
||||
"ISO27001:2022:5.15",
|
||||
"ISO27001:2022:5.18"
|
||||
]
|
||||
},
|
||||
"Method": {
|
||||
"Implementation": "To mitigate the risk of X, controls A, B and C will be implemented on asset Y by Responsible Z. The effectiveness will be measured through P and will be evaluated by Q according to method R, following planning S.",
|
||||
"Metrics": "Number of users with unjustly granted access to each application, compared to the necessary access following from the Job Framework",
|
||||
"Measurement": "The number of users with unjust access will be determined each quarter by HR, based on the current access matrix delivered by IT",
|
||||
"Evaluation": "The effectiveness of the control will be evaluated quarterly by the Compliance Officer in a meeting with HR and IT"
|
||||
},
|
||||
"ReviewsAndChanges": {
|
||||
"Review": "This policy will be reviewed yearly or if relevant and significant changes occur in the organization, in a meeting with the CISO, COO and Compliance Officer",
|
||||
"Changes": "Changes to this policy will be prepared by the policy o",
|
||||
"Responsibilities": {
|
||||
"PolicyWriting": "IT consultant",
|
||||
"PolicyApproval": "CISO",
|
||||
"Implementation": "IT Administration dept."
|
||||
}
|
||||
},
|
||||
"Documentation": {
|
||||
"PolicyDocuments": [],
|
||||
"ProcedureDescriptions": [],
|
||||
"MeasurementReports": [],
|
||||
"EvaluationReports": []
|
||||
}
|
||||
}
|
||||
```
|
||||
```JSON
|
||||
|
||||
```
|
||||
42
Drafts and Ideas/PolicyCard_Example_5.15.yaml
Normal file
42
Drafts and Ideas/PolicyCard_Example_5.15.yaml
Normal file
|
|
@ -0,0 +1,42 @@
|
|||
PolicyTitle: Application access policy
|
||||
RelevantStandardArticles:
|
||||
- ISO27001:2022:5.15
|
||||
- ISO27001:2022:5.18
|
||||
VersionControl:
|
||||
VersionNumber: '3.14'
|
||||
VersionDate: '2024-12-15'
|
||||
DocumentOwner: Alex Hanover
|
||||
ApprovedBy: Marian Faithful
|
||||
ApprovedDate: '2025-01-08'
|
||||
NextReview: '2025-12-15'
|
||||
Purpose:
|
||||
Goal: To protect classified data from unauthorized access
|
||||
Scope: All applications in use within the organization
|
||||
RisksMitigated: Unauthorized access to classified data
|
||||
ControlsImplemented:
|
||||
- ISO27001:2022:5.15
|
||||
- ISO27001:2022:5.18
|
||||
Method:
|
||||
Implementation: To mitigate the risk of X, controls A, B and C will be implemented
|
||||
on asset Y by Responsible Z. The effectiveness will be measured through P and
|
||||
will be evaluated by Q according to method R, following planning S.
|
||||
Metrics: Number of users with unjustly granted access to each application, compared
|
||||
to the necessary access following from the Job Framework
|
||||
Measurement: The number of users with unjust access will be determined each quarter
|
||||
by HR, based on the current access matrix delivered by IT
|
||||
Evaluation: The effectiveness of the control will be evaluated quarterly by the
|
||||
Compliance Officer in a meeting with HR and IT
|
||||
ReviewsAndChanges:
|
||||
Review: This policy will be reviewed yearly or if relevant and significant changes
|
||||
occur in the organization, in a meeting with the CISO, COO and Compliance Officer
|
||||
Changes: Changes to this policy will be prepared by the policy owner and proposed to the CISO.
|
||||
Responsibilities:
|
||||
PolicyWriting: IT consultant
|
||||
PolicyApproval: CISO
|
||||
Implementation: IT Administration dept.
|
||||
Documentation:
|
||||
PolicyDocuments: []
|
||||
ProcedureDescriptions: []
|
||||
ProofExecution: []
|
||||
MeasurementReports: []
|
||||
EvaluationReports: []
|
||||
12
Drafts and Ideas/iso27DIY Plain English Template.md
Normal file
12
Drafts and Ideas/iso27DIY Plain English Template.md
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
# Plain English Template
|
||||
|
||||
- Control ID - Title
|
||||
- Properties
|
||||
- In one sentence
|
||||
- Implementation Guidance
|
||||
- Required
|
||||
- Recommended
|
||||
- Relations to other clauses/controls/standards
|
||||
- Real life examples
|
||||
- Remarks
|
||||
|
||||
BIN
Server@Hostinger/.DS_Store
vendored
Normal file
BIN
Server@Hostinger/.DS_Store
vendored
Normal file
Binary file not shown.
5
Server@Hostinger/Hostinger How-to's.md
Normal file
5
Server@Hostinger/Hostinger How-to's.md
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
[VPS Setup Guide](https://www.hostinger.com/support/5723772-how-to-connect-to-your-vps-via-ssh-at-hostinger/)
|
||||
[Setting up the Firewall](https://www.hostinger.com/support/8172641-how-to-use-a-managed-vps-firewall-at-hostinger/)
|
||||
[Best practices](https://www.hostinger.com/tutorials/vps-security)
|
||||
[VPS monitoring with Kodee](https://www.youtube.com/watch?v=LpmOMzQDxFk)
|
||||
[VPS support articles](https://www.hostinger.com/support/vps/)
|
||||
228
Server@Hostinger/VPS administration.md
Normal file
228
Server@Hostinger/VPS administration.md
Normal file
|
|
@ -0,0 +1,228 @@
|
|||
# Onderhoudsplan — iso27diy.com VPS & analytics stack
|
||||
|
||||
## Dagelijks (geautomatiseerd)
|
||||
|
||||
Niets te doen — de volgende zaken lopen automatisch:
|
||||
|
||||
- fail2ban monitort SSH-pogingen en blokkeert aanvallers
|
||||
- Docker herstart Umami en PostgreSQL bij crashes (`restart: always`)
|
||||
- Nginx en fail2ban herstarten automatisch na een server-reboot (`systemctl enable`)
|
||||
- Let's Encrypt vernieuwt het SSL-certificaat automatisch via Certbot
|
||||
|
||||
---
|
||||
|
||||
## Wekelijks (~10 minuten)
|
||||
|
||||
### Services controleren
|
||||
|
||||
```bash
|
||||
# Nginx en fail2ban
|
||||
sudo systemctl status nginx fail2ban
|
||||
|
||||
# Umami en PostgreSQL
|
||||
cd ~/umami && docker compose ps
|
||||
```
|
||||
|
||||
Wat je wil zien: `active (running)` voor systemd-services, `running` voor Docker containers.
|
||||
|
||||
### fail2ban activiteit bekijken
|
||||
|
||||
```bash
|
||||
sudo fail2ban-client status sshd
|
||||
```
|
||||
|
||||
Veel bans op korte tijd kan wijzen op een gerichte aanval — overweeg dan `bantime` te verhogen in `jail.local`.
|
||||
|
||||
### Schijfruimte controleren
|
||||
|
||||
```bash
|
||||
df -h
|
||||
```
|
||||
|
||||
Let op de partitie waar `/` op staat. Bij meer dan 80% gebruik actie ondernemen (logs opruimen, Docker images opschonen).
|
||||
|
||||
### Docker logs vluchtig controleren
|
||||
|
||||
```bash
|
||||
cd ~/umami && docker compose logs --since 24h umami
|
||||
```
|
||||
|
||||
Zoek naar foutmeldingen of crashes.
|
||||
|
||||
---
|
||||
|
||||
## Maandelijks (~30 minuten)
|
||||
|
||||
### Systeemupdates installeren
|
||||
|
||||
```bash
|
||||
sudo apt update && apt list --upgradable
|
||||
sudo apt upgrade -y
|
||||
```
|
||||
|
||||
Herstart daarna de server als de kernel geüpdatet is:
|
||||
|
||||
```bash
|
||||
sudo reboot
|
||||
```
|
||||
|
||||
Controleer na herstart of alle services weer draaien (zie wekelijkse check).
|
||||
|
||||
### Umami updaten
|
||||
|
||||
```bash
|
||||
cd ~/umami
|
||||
docker compose pull
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
### Database backup maken
|
||||
|
||||
```bash
|
||||
docker compose exec db pg_dump -U umami umami > \
|
||||
~/umami/backup-$(date +%Y%m%d).sql
|
||||
```
|
||||
|
||||
Kopieer de backup naar een externe locatie (lokale machine of cloud opslag):
|
||||
|
||||
```bash
|
||||
# Vanaf je lokale machine:
|
||||
scp deploy@<server-ip>:~/umami/backup-$(date +%Y%m%d).sql ~/backups/
|
||||
```
|
||||
|
||||
Verwijder oude backups op de server (bewaar de laatste 3):
|
||||
|
||||
```bash
|
||||
ls -t ~/umami/backup-*.sql | tail -n +4 | xargs rm -f
|
||||
```
|
||||
|
||||
### SSL-certificaat controleren
|
||||
|
||||
```bash
|
||||
sudo certbot renew --dry-run
|
||||
```
|
||||
|
||||
Dit simuleert vernieuwing zonder het certificaat daadwerkelijk te vervangen. Als het slaagt, is automatische vernieuwing correct ingesteld.
|
||||
|
||||
Vervaldatum handmatig inzien:
|
||||
|
||||
```bash
|
||||
sudo certbot certificates
|
||||
```
|
||||
|
||||
### Nginx-logs bekijken op verdacht verkeer
|
||||
|
||||
```bash
|
||||
sudo tail -n 100 /var/log/nginx/access.log
|
||||
sudo tail -n 50 /var/log/nginx/error.log
|
||||
```
|
||||
|
||||
Veel 404-verzoeken op vreemde paden (bijv. `/wp-admin`, `/.env`) zijn normaal scannerverkeer — fail2ban pakt dit gedeeltelijk af. Bij aanhoudend verkeer van één IP kun je dat handmatig blokkeren:
|
||||
|
||||
```bash
|
||||
sudo ufw deny from <ip-adres>
|
||||
```
|
||||
|
||||
### Docker opschonen
|
||||
|
||||
Ongebruikte images en containers stapelen zich op en verbruiken schijfruimte:
|
||||
|
||||
```bash
|
||||
docker system prune -f
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Kwartaal (~1 uur)
|
||||
|
||||
### UTM campagnes updaten
|
||||
|
||||
- Voeg nieuwe campagnewaarden toe aan het UTM-scheme (nieuwe kwartaalcodes)
|
||||
- Archiveer verlopen campagnes in de UTM tracker spreadsheet (status → `archived`)
|
||||
- Controleer in Umami welke bronnen en campagnes het meest verkeer opleveren
|
||||
|
||||
### Wachtwoorden roteren
|
||||
|
||||
- Umami admin-wachtwoord wijzigen via **Settings → Profile**
|
||||
- Overweeg het database-wachtwoord in `docker-compose.yml` te roteren (vereist herstart van de stack)
|
||||
|
||||
### Firewall-regels reviewen
|
||||
|
||||
```bash
|
||||
sudo ufw status verbose
|
||||
```
|
||||
|
||||
Verwijder regels die niet meer nodig zijn.
|
||||
|
||||
### Serverresources evalueren
|
||||
|
||||
```bash
|
||||
# CPU en geheugen
|
||||
htop
|
||||
|
||||
# Schijfruimte per map
|
||||
du -sh ~/umami/*
|
||||
sudo du -sh /var/log/*
|
||||
```
|
||||
|
||||
Bij structureel hoog geheugen- of CPU-gebruik: overweeg een groter Hostinger-pakket.
|
||||
|
||||
---
|
||||
|
||||
## Bij incidenten
|
||||
|
||||
### Service ligt plat
|
||||
|
||||
```bash
|
||||
# Herstart individuele service
|
||||
sudo systemctl restart nginx
|
||||
sudo systemctl restart fail2ban
|
||||
cd ~/umami && docker compose restart
|
||||
```
|
||||
|
||||
### Umami dashboard niet bereikbaar
|
||||
|
||||
Controleer in volgorde:
|
||||
|
||||
1. Draaien de Docker containers? → `docker compose ps`
|
||||
2. Luistert Nginx? → `sudo systemctl status nginx`
|
||||
3. Klopt de DNS? → `dig analytics.iso27diy.com`
|
||||
4. Is het SSL-certificaat geldig? → `sudo certbot certificates`
|
||||
|
||||
### Database herstellen vanuit backup
|
||||
|
||||
```bash
|
||||
cd ~/umami
|
||||
docker compose stop umami
|
||||
docker compose exec db psql -U umami -c "DROP DATABASE umami;"
|
||||
docker compose exec db psql -U umami -c "CREATE DATABASE umami;"
|
||||
docker compose exec -T db psql -U umami umami < backup-YYYYMMDD.sql
|
||||
docker compose start umami
|
||||
```
|
||||
|
||||
### Jezelf buitengesloten via fail2ban
|
||||
|
||||
Doe dit vanaf een andere internetverbinding (bijv. mobiel):
|
||||
|
||||
```bash
|
||||
sudo fail2ban-client set sshd unbanip <jouw-ip>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Handige commando's — spiekbriefje
|
||||
|
||||
| Wat | Commando |
|
||||
|-----|----------|
|
||||
| Services checken | `sudo systemctl status nginx fail2ban` |
|
||||
| Docker containers checken | `cd ~/umami && docker compose ps` |
|
||||
| Schijfruimte | `df -h` |
|
||||
| fail2ban status | `sudo fail2ban-client status sshd` |
|
||||
| Umami logs | `cd ~/umami && docker compose logs -f umami` |
|
||||
| Nginx logs | `sudo tail -n 100 /var/log/nginx/access.log` |
|
||||
| Database backup | `docker compose exec db pg_dump -U umami umami > backup-$(date +%Y%m%d).sql` |
|
||||
| Systeem updaten | `sudo apt update && sudo apt upgrade -y` |
|
||||
| Umami updaten | `cd ~/umami && docker compose pull && docker compose up -d` |
|
||||
| Docker opschonen | `docker system prune -f` |
|
||||
| IP blokkeren | `sudo ufw deny from <ip>` |
|
||||
| IP deblokkeren (fail2ban) | `sudo fail2ban-client set sshd unbanip <ip>` |
|
||||
28
Server@Hostinger/VPS config.md
Normal file
28
Server@Hostinger/VPS config.md
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
# VPS configuratie
|
||||
|
||||
- srv1119777.hstgr.cloud
|
||||
- ssh root@72.61.188.15
|
||||
- IPv4: 72.61.188.15
|
||||
- IPv6: 2a02:4780:41:a7e5::1
|
||||
|
||||
* Plan: KVM 2 VPS, datacenter Frankfurt (DE), Verloopt op 2027-12-04
|
||||
* OS: Ubuntu 24.04 LTS
|
||||
* Resources: 8 GB RAM, 2 vCPU, 100 GB SSD (≈ 2.8 GB used), bandwidth 8 TB/maand (≈ 0.01% used)
|
||||
* Back-ups: Automatische dagelijkse back-up: **uitgeschakeld**
|
||||
|
||||
## Samenvatting gebruikte poorten en services
|
||||
per 10 April 2026
|
||||
|
||||
| Service | Poort | Bereikbaar vanaf |
|
||||
| --------------- | ------- | -------------------- |
|
||||
| Nginx | 80, 443 | Internet |
|
||||
| Umami (Node.js) | 3000 | Alleen localhost |
|
||||
| PostgreSQL | 5432 | Alleen Docker intern |
|
||||
Docker draait ook, natuurlijk
|
||||
|
||||
- [ ] regelmatig updates en backups draaien
|
||||
- [ ] logs draaien voor afwijkingen
|
||||
|
||||
## Samenvatting 11 april 2026
|
||||
|
||||
|
||||
449
Server@Hostinger/VPS install playbook.md
Normal file
449
Server@Hostinger/VPS install playbook.md
Normal file
|
|
@ -0,0 +1,449 @@
|
|||
# Stappenplan: Umami op Hostinger VPS
|
||||
|
||||
**Omgeving:** Ubuntu 24.04 LTS · 8 GB RAM · 2 vCPU · 100 GB SSD
|
||||
**Doel:** Umami analytics bereikbaar op `analytics.iso27diy.com`
|
||||
|
||||
---
|
||||
|
||||
## Overzicht
|
||||
|
||||
1. Server beveiligen (gebruiker, firewall, SSH)
|
||||
2. Docker installeren
|
||||
3. Subdomein aanmaken in Netlify DNS
|
||||
4. Umami deployen met Docker Compose
|
||||
5. Nginx instellen als reverse proxy
|
||||
6. SSL certificaat installeren (Let's Encrypt)
|
||||
7. Tracking script toevoegen aan Netlify site
|
||||
8. UTM-tracking testen
|
||||
|
||||
Geschatte tijd: **45–60 minuten**
|
||||
|
||||
---
|
||||
|
||||
## Stap 1 — Server beveiligen
|
||||
|
||||
### 1.1 Inloggen als root
|
||||
|
||||
```bash
|
||||
ssh root@<jouw-server-ip>
|
||||
```
|
||||
|
||||
### 1.2 Systeem updaten
|
||||
|
||||
```bash
|
||||
apt update && apt upgrade -y
|
||||
```
|
||||
|
||||
### 1.3 Nieuwe gebruiker aanmaken
|
||||
|
||||
Werken als root is risicovol. Maak een aparte gebruiker aan:
|
||||
|
||||
```bash
|
||||
adduser deploy
|
||||
usermod -aG sudo deploy
|
||||
```
|
||||
|
||||
Kies een sterk wachtwoord wanneer daarom gevraagd wordt.
|
||||
|
||||
### 1.4 SSH-toegang instellen voor nieuwe gebruiker
|
||||
|
||||
```bash
|
||||
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy
|
||||
```
|
||||
|
||||
Test in een **nieuw terminalvenster** (sluit de huidige sessie nog niet):
|
||||
|
||||
```bash
|
||||
ssh deploy@<jouw-server-ip>
|
||||
```
|
||||
|
||||
Als dat werkt: goed. Sluit nu de root-sessie.
|
||||
|
||||
### 1.5 Root-login via SSH uitschakelen
|
||||
|
||||
```bash
|
||||
sudo nano /etc/ssh/sshd_config
|
||||
```
|
||||
|
||||
Zoek de regel `PermitRootLogin yes` en verander die naar:
|
||||
|
||||
```
|
||||
PermitRootLogin no
|
||||
```
|
||||
|
||||
Sla op met `Ctrl+O`, sluit met `Ctrl+X`. Herstart SSH:
|
||||
|
||||
```bash
|
||||
sudo systemctl restart ssh
|
||||
```
|
||||
|
||||
### 1.6 Firewall instellen
|
||||
|
||||
```bash
|
||||
sudo ufw allow OpenSSH
|
||||
sudo ufw allow 80/tcp
|
||||
sudo ufw allow 443/tcp
|
||||
sudo ufw enable
|
||||
```
|
||||
|
||||
Controleer de status:
|
||||
|
||||
```bash
|
||||
sudo ufw status
|
||||
```
|
||||
|
||||
Je zou dit moeten zien:
|
||||
|
||||
```
|
||||
Status: active
|
||||
To Action From
|
||||
-- ------ ----
|
||||
OpenSSH ALLOW Anywhere
|
||||
80/tcp ALLOW Anywhere
|
||||
443/tcp ALLOW Anywhere
|
||||
```
|
||||
|
||||
|
||||
### 1.7 fail2ban installeren
|
||||
|
||||
```bash
|
||||
sudo apt install -y fail2ban
|
||||
```
|
||||
|
||||
Maak een configuratiebestand aan:
|
||||
|
||||
```bash
|
||||
sudo nano /etc/fail2ban/jail.local
|
||||
```
|
||||
|
||||
Plak:
|
||||
|
||||
```ini
|
||||
[DEFAULT]
|
||||
bantime = 1h
|
||||
findtime = 10m
|
||||
maxretry = 5
|
||||
|
||||
[sshd]
|
||||
enabled = true
|
||||
port = ssh
|
||||
logpath = %(sshd_log)s
|
||||
backend = %(sshd_backend)s
|
||||
```
|
||||
|
||||
Activeer en start:
|
||||
|
||||
```bash
|
||||
sudo systemctl enable fail2ban
|
||||
sudo systemctl start fail2ban
|
||||
```
|
||||
|
||||
Status controleren:
|
||||
|
||||
```bash
|
||||
sudo fail2ban-client status sshd
|
||||
```
|
||||
|
||||
Een gebanned IP handmatig deblokkeren:
|
||||
|
||||
```bash
|
||||
sudo fail2ban-client set sshd unbanip <ip-adres>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Stap 2 — Docker installeren
|
||||
|
||||
```bash
|
||||
sudo apt install -y ca-certificates curl gnupg
|
||||
sudo install -m 0755 -d /etc/apt/keyrings
|
||||
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
|
||||
sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
|
||||
echo \
|
||||
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
|
||||
https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
|
||||
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
|
||||
sudo apt update
|
||||
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
|
||||
```
|
||||
|
||||
Voeg je gebruiker toe aan de docker-groep (zodat je geen `sudo` nodig hebt):
|
||||
|
||||
```bash
|
||||
sudo usermod -aG docker deploy
|
||||
newgrp docker
|
||||
```
|
||||
|
||||
Test of het werkt:
|
||||
|
||||
```bash
|
||||
docker run hello-world
|
||||
```
|
||||
|
||||
---
|
||||
## Stap 3 — Subdomein aanmaken in Netlify DNS
|
||||
|
||||
Je domein `iso27diy.com` gebruikt Netlify als DNS. Zo voeg je het subdomein toe:
|
||||
|
||||
1. Log in op [app.netlify.com](https://app.netlify.com)
|
||||
2. Ga naar **Domains** (linksboven in het menu)
|
||||
3. Klik op `iso27diy.com`
|
||||
4. Klik op **Add new record**
|
||||
5. Vul in:
|
||||
- **Type:** `A`
|
||||
- **Name:** `analytics`
|
||||
- **Value:** `<jouw-server-ip>` (het IP-adres van je Hostinger VPS)
|
||||
- **TTL:** laat op standaard staan
|
||||
1. Klik **Save**
|
||||
|
||||
Het DNS-record propageert doorgaans binnen 5–15 minuten. Je kunt het controleren via:
|
||||
|
||||
```bash
|
||||
dig analytics.iso27diy.com
|
||||
```
|
||||
|
||||
Wacht met de volgende stap tot het IP-adres correct terugkomt.
|
||||
|
||||
---
|
||||
|
||||
## Stap 4 — Umami deployen met Docker Compose
|
||||
|
||||
### 4.1 Map aanmaken
|
||||
|
||||
```bash
|
||||
mkdir -p ~/umami && cd ~/umami
|
||||
```
|
||||
|
||||
### 4.2 docker-compose.yml aanmaken
|
||||
|
||||
```bash
|
||||
nano docker-compose.yml
|
||||
```
|
||||
|
||||
Plak de volgende inhoud:
|
||||
|
||||
```yaml
|
||||
version: '3'
|
||||
|
||||
services:
|
||||
umami:
|
||||
image: ghcr.io/umami-software/umami:postgresql-latest
|
||||
ports:
|
||||
- "127.0.0.1:3000:3000"
|
||||
environment:
|
||||
DATABASE_URL: postgresql://umami:umami_password@db:5432/umami
|
||||
DATABASE_TYPE: postgresql
|
||||
APP_SECRET: vervang_dit_door_een_willekeurige_lange_string
|
||||
depends_on:
|
||||
db:
|
||||
condition: service_healthy
|
||||
restart: always
|
||||
|
||||
db:
|
||||
image: postgres:15-alpine
|
||||
environment:
|
||||
POSTGRES_DB: umami
|
||||
POSTGRES_USER: umami
|
||||
POSTGRES_PASSWORD: umami_password
|
||||
volumes:
|
||||
- umami-db:/var/lib/postgresql/data
|
||||
healthcheck:
|
||||
test: ["CMD-SHELL", "pg_isready -U umami"]
|
||||
interval: 5s
|
||||
timeout: 5s
|
||||
retries: 5
|
||||
restart: always
|
||||
|
||||
volumes:
|
||||
umami-db:
|
||||
```
|
||||
|
||||
**Belangrijk:** vervang `umami_password` door een sterk wachtwoord, en `vervang_dit_door_een_willekeurige_lange_string` door een willekeurige string (bijv. via `openssl rand -base64 32`).
|
||||
|
||||
Genereer een willekeurige APP_SECRET:
|
||||
|
||||
```bash
|
||||
openssl rand -base64 32
|
||||
```
|
||||
|
||||
Kopieer de output en plak die als waarde voor `APP_SECRET`.
|
||||
|
||||
Sla op met `Ctrl+O`, sluit met `Ctrl+X`.
|
||||
|
||||
### 4.3 Umami starten
|
||||
|
||||
```bash
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
Controleer of de containers draaien:
|
||||
|
||||
```bash
|
||||
docker compose ps
|
||||
```
|
||||
|
||||
Beide services (`umami` en `db`) moeten de status `running` hebben. Dit kan 1–2 minuten duren bij de eerste start.
|
||||
|
||||
Controleer de logs als iets niet klopt:
|
||||
|
||||
```bash
|
||||
docker compose logs -f
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Stap 5 — Nginx instellen als reverse proxy
|
||||
|
||||
Nginx ontvangt het verkeer op poort 80/443 en stuurt het door naar Umami op poort 3000.
|
||||
|
||||
### 5.1 Nginx installeren
|
||||
|
||||
```bash
|
||||
sudo apt install -y nginx
|
||||
```
|
||||
|
||||
### 5.2 Configuratie aanmaken
|
||||
|
||||
```bash
|
||||
sudo nano /etc/nginx/sites-available/analytics.iso27diy.com
|
||||
```
|
||||
|
||||
Plak:
|
||||
|
||||
```nginx
|
||||
server {
|
||||
listen 80;
|
||||
server_name analytics.iso27diy.com;
|
||||
|
||||
location / {
|
||||
proxy_pass http://127.0.0.1:3000;
|
||||
proxy_http_version 1.1;
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Connection 'upgrade';
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
proxy_cache_bypass $http_upgrade;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Sla op en sluit.
|
||||
|
||||
### 5.3 Configuratie activeren
|
||||
|
||||
```bash
|
||||
sudo ln -s /etc/nginx/sites-available/analytics.iso27diy.com \
|
||||
/etc/nginx/sites-enabled/
|
||||
sudo nginx -t
|
||||
sudo systemctl reload nginx
|
||||
```
|
||||
|
||||
`nginx -t` moet `syntax is ok` teruggeven.
|
||||
|
||||
---
|
||||
|
||||
## Stap 6 — SSL certificaat installeren
|
||||
|
||||
```bash
|
||||
sudo apt install -y certbot python3-certbot-nginx
|
||||
sudo certbot --nginx -d analytics.iso27diy.com
|
||||
```
|
||||
|
||||
Certbot vraagt om een e-mailadres en of je akkoord gaat met de voorwaarden. Na afloop past het de Nginx-configuratie automatisch aan voor HTTPS en regelt het automatische verlenging.
|
||||
|
||||
Controleer automatische verlenging:
|
||||
|
||||
```bash
|
||||
sudo certbot renew --dry-run
|
||||
```
|
||||
|
||||
---
|
||||
## Stap 7 — Eerste login en wachtwoord wijzigen
|
||||
|
||||
Ga naar `https://analytics.iso27diy.com` in je browser.
|
||||
|
||||
- **Gebruikersnaam:** `admin`
|
||||
- **Wachtwoord:** `umami`
|
||||
|
||||
Ga direct naar **Settings → Profile** en stel een sterk wachtwoord in.
|
||||
|
||||
|
||||
### Website toevoegen
|
||||
|
||||
1. Ga naar **Settings → Websites → Add website**
|
||||
2. Vul in:
|
||||
- **Name:** iso27diy.com
|
||||
- **Domain:** iso27diy.com
|
||||
3. Klik **Save**
|
||||
4. Klik op het **tracking code** icoontje naast de website om je `data-website-id` te kopiëren
|
||||
|
||||
---
|
||||
## Stap 8 — Tracking script toevoegen aan Netlify site
|
||||
|
||||
Voeg dit toe aan de `<head>` van je site. Hoe je dat doet hangt af van hoe je site gebouwd is, maar in de meeste gevallen is er een hoofd-HTML-template.
|
||||
|
||||
```html
|
||||
<script
|
||||
defer
|
||||
src="https://analytics.iso27diy.com/script.js"
|
||||
data-website-id="jouw-website-id-hier"
|
||||
data-domains="iso27diy.com">
|
||||
</script>
|
||||
```
|
||||
|
||||
Het `data-domains` attribuut zorgt dat bezoeken vanaf andere domeinen (zoals localhost tijdens ontwikkeling) niet meegeteld worden.
|
||||
|
||||
Na een Netlify deploy: ga naar je site, wacht een paar seconden, en controleer of er een bezoek verschijnt in het Umami dashboard onder **Realtime**.
|
||||
|
||||
---
|
||||
|
||||
## Stap 9 — UTM-tracking testen
|
||||
|
||||
Maak een test-URL met UTM-parameters:
|
||||
|
||||
```
|
||||
https://iso27diy.com/?utm_source=linkedin&utm_medium=post&utm_campaign=test&utm_content=cta-hero
|
||||
```
|
||||
|
||||
Bezoek die URL in een browser. Ga dan in Umami naar:
|
||||
|
||||
**Reports → UTM** (of in het hoofddashboard onder **Sources**)
|
||||
|
||||
Je ziet daar de uitsplitsing per `source`, `medium`, `campaign` en `content`.
|
||||
|
||||
---
|
||||
|
||||
## Updates uitvoeren
|
||||
|
||||
Umami brengt regelmatig updates uit. Updaten gaat zo:
|
||||
|
||||
```bash
|
||||
cd ~/umami
|
||||
docker compose pull
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Database backup
|
||||
|
||||
Railway maakte geen automatische backups — op je eigen VPS ook niet, tenzij je dat instelt. Maak periodiek een handmatige backup:
|
||||
|
||||
```bash
|
||||
docker compose exec db pg_dump -U umami umami > \
|
||||
~/umami/backup-$(date +%Y%m%d).sql
|
||||
```
|
||||
|
||||
Bewaar backups op een andere locatie (bijv. je lokale machine of een cloud opslag).
|
||||
|
||||
---
|
||||
|
||||
## Samenvatting gebruikte poorten en services
|
||||
|
||||
| Service | Poort | Bereikbaar vanaf |
|
||||
| --------------- | ------- | -------------------- |
|
||||
| Nginx | 80, 443 | Internet |
|
||||
| Umami (Node.js) | 3000 | Alleen localhost |
|
||||
| PostgreSQL | 5432 | Alleen Docker intern |
|
||||
24
Server@Hostinger/VPS security.md
Normal file
24
Server@Hostinger/VPS security.md
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
# VPS Beveiligingsmaatregelen
|
||||
|
||||
### Server hardening
|
||||
- Root SSH-login uitgeschakeld
|
||||
- Dedicated non-root gebruiker (`deploy`) met sudo-rechten
|
||||
- SSH key authenticatie
|
||||
- UFW firewall — alleen poorten 22, 80 en 443 open
|
||||
- fail2ban actief — IP-adressen worden 1 uur geblokkeerd na 5 mislukte SSH-pogingen binnen 10 minuten
|
||||
|
||||
### Netwerk & encryptie
|
||||
- HTTPS afgedwongen via Nginx + Let's Encrypt
|
||||
- Umami gebonden aan `127.0.0.1` — niet publiek bereikbaar
|
||||
- PostgreSQL alleen op intern Docker-netwerk
|
||||
- SSL automatisch vernieuwd via Certbot
|
||||
|
||||
### Applicatiebeveiliging
|
||||
- Umami standaardwachtwoord direct wijzigen bij eerste login
|
||||
- `APP_SECRET` gerandomiseerd met `openssl rand -base64 32`
|
||||
- Cookieloze tracking — geen persoonsgegevens opgeslagen
|
||||
- `data-domains` attribuut beperkt tracking tot productiedomein
|
||||
|
||||
### Nog te doen
|
||||
- [ ] Periodieke database backups instellen (cronjob) — een cronjob op de VPS die dagelijks een dump maakt en bijv. naar je lokale machine of een object storage stuurt. Nu verlies je bij een VPS-crash alles wat na je laatste handmatige backup binnenkomt.
|
||||
- [ ] fail2ban installeren voor SSH brute-force bescherming — blokkeert automatisch IP-adressen die te vaak fout inloggen via SSH. Eén commando om te installeren, vrijwel geen configuratie nodig.
|
||||
18
Server@Hostinger/VPS stack.md
Normal file
18
Server@Hostinger/VPS stack.md
Normal file
|
|
@ -0,0 +1,18 @@
|
|||
# VPS Infrastructure stack
|
||||
per 11 April 2026
|
||||
|
||||
| Component | Details | Platform |
|
||||
|-----------|---------|----------|
|
||||
| Website hosting | iso27diy.com — statische site | Netlify |
|
||||
| DNS | iso27diy.com + analytics.iso27diy.com | Netlify DNS |
|
||||
| Domeinregistrar | iso27diy.com gekocht hier | Hover |
|
||||
| VPS | Ubuntu 24.04 · 8 GB RAM · 2 vCPU · 100 GB SSD | Hostinger |
|
||||
| Analytics app | analytics.iso27diy.com · poort 3000 (intern) | Umami |
|
||||
| Database | PostgreSQL 15 · alleen Docker intern netwerk | Docker |
|
||||
| Reverse proxy | Handelt HTTPS af, stuurt door naar Umami op :3000 | Nginx |
|
||||
| SSL | Automatisch vernieuwd · analytics.iso27diy.com | Let's Encrypt |
|
||||
| fail2ban | SSH brute-force bescherming | Hostinger VPS |
|
||||
|
||||
---
|
||||
|
||||
[[VPS security]]
|
||||
96
Website/Code/Bulma and SASS typography control.md
Normal file
96
Website/Code/Bulma and SASS typography control.md
Normal file
|
|
@ -0,0 +1,96 @@
|
|||
# Typography with Bulma and SASS
|
||||
|
||||
https://bulma.io/documentation/
|
||||
https://github.com/jgthms/bulma
|
||||
https://www.w3schools.com/sass/sass_intro.asp
|
||||
|
||||
Bulma provides several options for configuring **typography**, both through **utility classes** and **Sass variables** for customization. Most of the time, you apply Bulma classes directly in your HTML, because Bulma is a CSS framework that defines classes to be used in HTML.
|
||||
|
||||
Example:
|
||||
```html
|
||||
<p class="has-text-weight-bold has-text-centered">
|
||||
Bold and centered text
|
||||
</p>
|
||||
```
|
||||
|
||||
You *would* use the CSS Selectors (in your CSS files) if you want to customize the Bulma classes, for example:
|
||||
```css
|
||||
|
||||
# Override existing Bulma style
|
||||
|
||||
.has-text-weight-bold {
|
||||
color: #ff0000; /* Custom override */
|
||||
}
|
||||
|
||||
# Adding custom styles to elements that already use Bulma classes
|
||||
|
||||
.title.has-text-centered {
|
||||
text-transform: uppercase;
|
||||
}
|
||||
|
||||
# Creating custom components to extend Bulma
|
||||
|
||||
.custom-card .title {
|
||||
font-family: 'Lora', serif;
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
## 1. Bulma Typography Classes
|
||||
|
||||
Bulma includes these predefined classes for text styling:
|
||||
|
||||
| **Description** | **CSS Selector** | **HTML Usage** |
|
||||
| ----------------------- | ------------------------------------ | -------------------------------------------- |
|
||||
| Title | `.title` | `<h1 class="title">Heading</h1>` |
|
||||
| Subtitle | `.subtitle` | `<h2 class="subtitle">Subheading</h2>` |
|
||||
| Title size modifiers | `.title.is-1` to `.title.is-6` | `<h1 class="title is-1">Heading</h1>` |
|
||||
| Subtitle size modifiers | `.subtitle.is-1` to `.subtitle.is-6` | `<h2 class="subtitle is-3">Subheading</h2>` |
|
||||
| Alignment left | `.has-text-left` | `<p class="has-text-left">Text</p>` |
|
||||
| Alignment center | `.has-text-centered` | `<p class="has-text-centered">Text</p>` |
|
||||
| Alignment right | `.has-text-right` | `<p class="has-text-right">Text</p>` |
|
||||
| Color primary | `.has-text-primary` | `<p class="has-text-primary">Text</p>` |
|
||||
| Color danger | `.has-text-danger` | `<p class="has-text-danger">Text</p>` |
|
||||
| Weight light | `.has-text-weight-light` | `<p class="has-text-weight-light">Text</p>` |
|
||||
| Weight normal | `.has-text-weight-normal` | `<p class="has-text-weight-normal">Text</p>` |
|
||||
| Weight bold | `.has-text-weight-bold` | `<p class="has-text-weight-bold">Text</p>` |
|
||||
| Uppercase text | `.is-uppercase` | `<p class="is-uppercase">Text</p>` |
|
||||
| Lowercase text | `.is-lowercase` | `<p class="is-lowercase">Text</p>` |
|
||||
| Capitalized text | `.is-capitalized` | `<p class="is-capitalized">Text</p>` |
|
||||
| Text size modifiers | `.is-size-1` to `.is-size-7` | `<p class="is-size-3">Text</p>` |
|
||||
| Responsive text size | `.is-size-4-mobile` etc. | `<p class="is-size-4-mobile">Text</p>` |
|
||||
|
||||
## 2. Sass typography variables
|
||||
|
||||
You can customize typography **globally** using Bulma’s Sass variables. This happens in your custom `.scss` file. Example:
|
||||
```scss
|
||||
$family-primary: 'Roboto', sans-serif;
|
||||
$body-size: 16px;
|
||||
$weight-bold: 700;
|
||||
@import "bulma";
|
||||
```
|
||||
|
||||
**Font Family**
|
||||
- `$family-primary` – Main font
|
||||
- `$family-secondary` – Alternative font
|
||||
- `$family-code` – Monospace font
|
||||
|
||||
**Font Sizes**
|
||||
- `$size-1` to `$size-7` – Heading sizes
|
||||
- `$body-size` – Base font size
|
||||
|
||||
**Font Weights**
|
||||
- `$weight-light`
|
||||
- `$weight-normal`
|
||||
- `$weight-semibold`
|
||||
- `$weight-bold`
|
||||
|
||||
**Line Height**
|
||||
- `$body-line-height`
|
||||
|
||||
**Text Colors**
|
||||
- `$text` – Default text color
|
||||
- `$text-strong` – Strong text color
|
||||
- `$link` – Link color
|
||||
|
||||
|
||||
115
Website/Code/Bulma frontend components.md
Normal file
115
Website/Code/Bulma frontend components.md
Normal file
|
|
@ -0,0 +1,115 @@
|
|||
Bulma is a modern CSS framework based on Flexbox.
|
||||
https://bulma.io/
|
||||
https://github.com/jgthms/bulma
|
||||
|
||||
# Common frontend components
|
||||
|
||||
**Layout:**
|
||||
|
||||
- **Container** – Centers and constrains content width.
|
||||
- **Section** – Large spacing block for grouping content.
|
||||
- **Hero** – Full-width banner for headers or landing pages.
|
||||
- **Footer** – Page footer area.
|
||||
- **Columns** – Responsive grid system using Flexbox.
|
||||
- **Tile** – Complex layouts for cards and media objects.
|
||||
|
||||
|
||||
**Navigation:**
|
||||
|
||||
- **Navbar** – Responsive navigation bar with branding and links.
|
||||
- **Tabs** – Horizontal tab navigation.
|
||||
- **Breadcrumb** – Hierarchical navigation trail.
|
||||
- **Pagination** – Page navigation controls.
|
||||
|
||||
|
||||
**Forms:**
|
||||
|
||||
- **Input** – Text fields, email, password, etc.
|
||||
- **Textarea** – Multi-line text input.
|
||||
- **Select** – Dropdown menus.
|
||||
- **Checkbox & Radio** – Form controls.
|
||||
- **File Upload** – Styled file input.
|
||||
- **Buttons** – Primary, link, outlined, etc.
|
||||
- **Field & Control** – Form grouping and alignment.
|
||||
|
||||
|
||||
**Content:**
|
||||
|
||||
- **Typography** – Titles, subtitles, headings, text helpers.
|
||||
- **Image** – Responsive image container.
|
||||
- **Icon** – Font Awesome or custom icons.
|
||||
- **Media Object** – Layout for image + text.
|
||||
- **Notification** – Alert messages.
|
||||
- **Tag** – Small label elements.
|
||||
- **Progress Bar** – Loading indicators.
|
||||
|
||||
|
||||
**Cards & Panels:**
|
||||
|
||||
- **Card** – Content container with header, body, footer.
|
||||
- **Panel** – Sidebar-like component for menus or lists.
|
||||
- **Box** – Simple bordered container.
|
||||
|
||||
|
||||
**Modals & Interactives:**
|
||||
|
||||
- **Modal** – Popup dialog.
|
||||
- **Dropdown** – Interactive menu.
|
||||
- **Message** – Dismissible alert box.
|
||||
- **Tooltip** – Hover info (requires JS).
|
||||
|
||||
|
||||
**Helpers & Utilities:**
|
||||
|
||||
- **Spacing Helpers** – Margin/padding classes.
|
||||
- **Color Helpers** – Text and background colors.
|
||||
- **Visibility Helpers** – Show/hide on breakpoints.
|
||||
- **Flexbox Helpers** – Alignment and distribution.
|
||||
|
||||
## Component Reference Table
|
||||
|
||||
| **Component** | **Description** | **Bulma Classes** | **Sass Customization Tips** |
|
||||
| ---------------------- | ------------------------------------------------- | ------------------------------------------ | ------------------------------------------------------- |
|
||||
| <br>**Layout** | | | |
|
||||
| Container | Centers content and sets max width | `.container` | `$container-max-width` |
|
||||
| Section | Large spacing block for grouping content | `.section` | `$section-padding` |
|
||||
| Hero | Full-width banner for headers or landing pages | `.hero`, `.hero-body` | `$hero-body-padding`, `$hero-background-color` |
|
||||
| Footer | Page footer area | `.footer` | `$footer-background-color`, `$footer-padding` |
|
||||
| Columns | Responsive grid system using Flexbox | `.columns`, `.column` | `$column-gap`, `$column-padding` |
|
||||
| Tile | Complex layouts for cards and media objects | `.tile` | `$tile-spacing` |
|
||||
| <br>**Navigation** | | | |
|
||||
| Navbar | Responsive navigation bar with branding and links | `.navbar`, `.navbar-item` | `$navbar-background-color`, `$navbar-height` |
|
||||
| Tabs | Horizontal tab navigation | `.tabs`, `.is-active` | `$tabs-border-color`, `$tabs-link-color` |
|
||||
| Breadcrumb | Hierarchical navigation trail | `.breadcrumb` | `$breadcrumb-item-color`, `$breadcrumb-separator-color` |
|
||||
| Pagination | Page navigation controls | `.pagination`, `.pagination-link` | `$pagination-color`, `$pagination-hover-color` |
|
||||
| <br>**Forms** | | | |
|
||||
| Input | Text fields, email, password, etc. | `.input` | `$input-background-color`, `$input-border-color` |
|
||||
| Textarea | Multi-line text input | `.textarea` | `$textarea-background-color` |
|
||||
| Select | Dropdown menus | `.select` | `$select-background-color` |
|
||||
| Checkbox & Radio | Form controls | `.checkbox`, `.radio` | `$control-margin` |
|
||||
| File Upload | Styled file input | `.file` | `$file-cta-background-color`, `$file-name-color` |
|
||||
| Buttons | Primary, link, outlined, etc. | `.button`, `.is-primary`, `.is-link` | `$button-background-color`, `$button-border-radius` |
|
||||
| Field & Control | Form grouping and alignment | `.field`, `.control` | `$field-margin`, `$control-padding` |
|
||||
| <br>**Content** | | | |
|
||||
| Typography | Titles, subtitles, headings, text helpers | `.title`, `.subtitle`, `.has-text-*` | `$title-color`, `$subtitle-color` |
|
||||
| Image | Responsive image container | `.image` | `$image-radius` |
|
||||
| Icon | Font Awesome or custom icons | `.icon` | `$icon-size` |
|
||||
| Media Object | Layout for image + text | `.media`, `.media-left`, `.media-content` | `$media-spacing` |
|
||||
| Notification | Alert messages | `.notification` | `$notification-background-color` |
|
||||
| Tag | Small label elements | `.tag` | `$tag-background-color`, `$tag-radius` |
|
||||
| Progress Bar | Loading indicators | `.progress` | `$progress-bar-background-color` |
|
||||
| <br>**Cards & Panels** | | | |
|
||||
| Card | Content container with header, body, footer | `.card`, `.card-header`, `.card-footer` | `$card-radius`, `$card-shadow` |
|
||||
| Panel | Sidebar-like component for menus or lists | `.panel`, `.panel-block` | `$panel-background-color`, `$panel-border-color` |
|
||||
| Box | Simple bordered container | `.box` | `$box-radius`, `$box-shadow` |
|
||||
| Interactive | | | |
|
||||
| Modal | Popup dialog | `.modal`, `.modal-content` | `$modal-background-color`, `$modal-radius` |
|
||||
| Dropdown | Interactive menu | `.dropdown`, `.dropdown-menu` | `$dropdown-background-color`, `$dropdown-radius` |
|
||||
| Message | Dismissible alert box | `.message`, `.message-header` | `$message-background-color`, `$message-radius` |
|
||||
| Tooltip | Hover info (requires JS) | `.has-tooltip` | `$tooltip-background-color`, `$tooltip-radius` |
|
||||
| <br>**Helpers** | | | |
|
||||
| Spacing Helpers | Margin/padding classes | `.m-*`, `.p-*` | `$spacing-scale` |
|
||||
| Color Helpers | Text and background colors | `.has-text-*`, `.has-background-*` | `$colors` map |
|
||||
| Visibility | Show/hide on breakpoints | `.is-hidden-*`, `.is-flex-*` | `$breakpoints` map |
|
||||
| Flexbox Helpers | Alignment and distribution | `.is-flex`, `.is-justify-*`, `.is-align-*` | `$flexbox-helpers` |
|
||||
|
||||
237
Website/Code/Working a Hugo website.md
Normal file
237
Website/Code/Working a Hugo website.md
Normal file
|
|
@ -0,0 +1,237 @@
|
|||
# Working a Hugo website
|
||||
|
||||
## The Rendering Pipeline
|
||||
|
||||
- Global settings are defined in `hugo.toml`, like theme, params, baseURL, and build/minify behavior.
|
||||
- `baseof.html`[^2] provides the core HTML structure shared by *all* pages, including:
|
||||
- HTML boilerplate
|
||||
- Site-wide metadata (charset, viewport)
|
||||
- Title generation
|
||||
- CSS and navigation bar
|
||||
- A placeholder block `{{ block "main" . }}{{ end }}` for page-specific content
|
||||
- Footer
|
||||
- `index.html` is the homepage template - It extends the base template and fills in the main block with homepage-specific content organized in partials.
|
||||
|
||||
**Processing**
|
||||
1. Hugo renders `layouts/index.html` , which starts with `{{ define "main" }}` to define a main block to replace the one in `baseof.html`.
|
||||
2. Hugo renders the base template
|
||||
3. `index.html` pulls in partials from `layouts/partials/…`.
|
||||
4. Partials pull data from `data/homepage.yaml` (and `.Site.Params` in `hugo.toml`).
|
||||
5. HTML files use compiled CSS from `assets/custom.scss`[^1].
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
## To add a section
|
||||
|
||||
To add (or remove) a section, modify the following files:
|
||||
|
||||
1. Add the content data for the new section in `data/homepage.yaml`
|
||||
2. Create `layouts/partials/newSection.html`
|
||||
3. Update `layouts/index.html` to call the new partial at the place you want it to show
|
||||
|
||||
|
||||
---
|
||||
|
||||
## File-by-file: roles and interplay
|
||||
|
||||
### 1) `assets/custom.scss` (your SCSS entry point)
|
||||
|
||||
- **What it is:** An SCSS source file that Hugo compiles into CSS using **Hugo Pipes** with **Dart Sass** (you’re on Hugo Extended via v0.154.2, so that’s supported).
|
||||
- **What it does:**
|
||||
- Imports **Bulma v1** (either via `@use`/`@forward` if you vendored it under `assets/`, or a pre-bundled CSS file if you prefer).
|
||||
- Sets Bulma variables (colors, spacing, breakpoints) **before** importing Bulma to override defaults.
|
||||
- Adds your theme overrides for Fresh components/sections and custom utilities.
|
||||
- **How it’s wired in:**\ A head partial (commonly something like `layouts/partials/head.html`) will contain Hugo Pipes calls:
|
||||
|
||||
{{ $styles := resources.Get "custom.scss" | toCSS (dict "targetPath" "assets/custom.css") | minify | fingerprint }}
|
||||
|
||||
<link rel="stylesheet" href="{{ $styles.RelPermalink }}" integrity="{{ $styles.Data.Integrity }}">
|
||||
|
||||
This line is what **connects your SCSS to the HTML**. If you don’t see it yet, add it to your head partial.
|
||||
|
||||
> **Override rules:** If the theme also ships a `assets/custom.scss`, your project-level `assets/custom.scss` **overrides the theme’s** because of Hugo’s lookup order.
|
||||
|
||||
---
|
||||
|
||||
### 2) `layouts/index.html` (homepage template)
|
||||
|
||||
- **What it is:** The template used for the site’s root (`/`). Hugo’s template lookup will use this file if present in your project (it **overrides the theme’s** `index.html`).
|
||||
- **What it does:**
|
||||
- Defines the **page structure** of your homepage.
|
||||
- **Includes partials** that render each section (hero, features, testimonials, CTAs).
|
||||
- Passes data to partials—commonly **from** `.Site.Data.homepage` (i.e., `data/homepage.yaml`) or `.Site.Params`.
|
||||
- **Typical pattern:**
|
||||
|
||||
{{ define "main" }}
|
||||
|
||||
{{ partial "hero.html" (dict "ctx" . "data" .Site.Data.homepage.hero) }}
|
||||
|
||||
{{ partial "features.html" (dict "ctx" . "data" .Site.Data.homepage.features) }}
|
||||
|
||||
{{ partial "cta.html" (dict "ctx" . "data" .Site.Data.homepage.cta) }}
|
||||
|
||||
{{ end }}
|
||||
|
||||
This shows how the template **connects to your data file**.
|
||||
|
||||
---
|
||||
|
||||
### 3) `layouts/partials/` (reusable sections & head)
|
||||
|
||||
- **What it is:** A folder of small templates used by pages (and other partials).
|
||||
- **What it does:**
|
||||
- Renders **modular sections** like `hero.html`, `navbar.html`, `footer.html`, `features.html`, `pricing.html`, etc.
|
||||
- Contains **`head.html`** or similar where you wire in **`assets/custom.scss`** via Hugo Pipes (see above).
|
||||
- Optionally injects JavaScript assets (minified/fingerprinted in a similar way).
|
||||
- **How it connects:**\ Partials receive a context. If you pass a dict with `"data"`, the partial can render purely from that structure:
|
||||
|
||||
{{ $d := .data }}
|
||||
|
||||
<section class="section hero is-primary">
|
||||
|
||||
<div class="container">
|
||||
|
||||
<h1 class="title">{{ $d.title }}</h1>
|
||||
|
||||
<p class="subtitle">{{ $d.subtitle }}</p>
|
||||
|
||||
{{ with $d.buttons }}
|
||||
|
||||
<div class="buttons">
|
||||
|
||||
{{ range . }}
|
||||
|
||||
<a class="button is-{{ .color }}" href="{{ .url }}">{{ .label }}</a>
|
||||
|
||||
{{ end }}
|
||||
|
||||
</div>
|
||||
|
||||
{{ end }}
|
||||
|
||||
</div>
|
||||
|
||||
</section>
|
||||
|
||||
This keeps your **content in `data/homepage.yaml`** and your **structure in partials**.
|
||||
|
||||
> **Override rules:** Project partials in `layouts/partials/` override theme partials of the same path/name. This is how you customize Fresh without forking the theme.
|
||||
|
||||
---
|
||||
|
||||
### 4) `data/homepage.yaml` (structured content for the homepage)
|
||||
|
||||
- **What it is:** A data file (YAML) containing **content & per-section settings** for the homepage: texts, images, lists, buttons, visibility flags.
|
||||
- **What it does:**
|
||||
- Decouples content from templates: editors can update text without touching HTML/SCSS.
|
||||
- Supplies data to partials via `.Site.Data.homepage` or by passing nested keys.
|
||||
- **Typical shape (example):**
|
||||
|
||||
hero:
|
||||
|
||||
title: "Build fast with Fresh + Bulma v1"
|
||||
|
||||
subtitle: "A clean landing page powered by Hugo"
|
||||
|
||||
buttons:
|
||||
|
||||
- label: "Get Started"
|
||||
|
||||
url: "/docs"
|
||||
|
||||
color: "primary"
|
||||
|
||||
- label: "GitHub"
|
||||
|
||||
url: "https://github.com/…"
|
||||
|
||||
color: "light"
|
||||
|
||||
|
||||
|
||||
features:
|
||||
|
||||
items:
|
||||
|
||||
- icon: "rocket"
|
||||
|
||||
title: "Speedy"
|
||||
|
||||
text: "Hugo builds are blazing fast."
|
||||
|
||||
- icon: "feather"
|
||||
|
||||
title: "Lightweight"
|
||||
|
||||
text: "No heavy JS framework required."
|
||||
|
||||
- **How it connects:**\ A partial will read it like `.Site.Data.homepage.hero.title` (or via the `"data"` key passed from the index template).
|
||||
|
||||
> **Override rules:** Your project’s `data/` completely defines the data used. If the theme ships default YAML in its `data/`, **your project’s files win**.
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
|
||||
## Common customization patterns
|
||||
|
||||
- **Change copy or lists** → edit `data/homepage.yaml`.
|
||||
- **Change section structure or classes** → edit the corresponding `layouts/partials/*.html`.
|
||||
- **Add a new section** →
|
||||
1. create a new partial `layouts/partials/your-section.html`,
|
||||
2. add data under `data/homepage.yaml` (e.g., `yourSection:`),
|
||||
3. include the partial from `layouts/index.html`: {{ partial "your-section.html" (dict "ctx" . "data" .Site.Data.homepage.yourSection) }}
|
||||
- **Adjust colors/spacing/fonts** → edit `assets/custom.scss` (set Bulma variables before importing Bulma; add your custom rules after).
|
||||
- **Add/optimize assets** → wire them in the head/footer partials with Hugo Pipes (minify, fingerprint).
|
||||
|
||||
---
|
||||
|
||||
## Notes for Bulma v1 + Dart Sass + Fresh
|
||||
|
||||
- **Variable overrides:**\ With Dart Sass, prefer `@use`/`@forward`:
|
||||
|
||||
// assets/custom.scss
|
||||
|
||||
@use "bulma/sass" with (
|
||||
|
||||
$primary: #4e7cf3,
|
||||
|
||||
$family-sans-serif: "Inter", system-ui, -apple-system, "Segoe UI", Roboto, Arial, sans-serif,
|
||||
|
||||
$body-background-color: #fff
|
||||
|
||||
);
|
||||
|
||||
|
||||
|
||||
// Your component overrides after Bulma is loaded
|
||||
|
||||
.navbar.is-transparent { background-color: transparent; }
|
||||
|
||||
Ensure Bulma’s source is available under `assets/` (e.g., `assets/bulma/…`) or adjust the import path accordingly.
|
||||
|
||||
- **Lookup order helps you customize safely:**\ Put overrides in your project (`layouts`, `assets`, `data`). You avoid forking the theme and keep upgrades simpler.
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Quick sanity checklist
|
||||
|
||||
- **Head partial includes your SCSS:** Confirm a link tag is generated via `resources.Get "custom.scss" | toCSS …`.
|
||||
- **Homepage uses your `index.html`:** Run `hugo server` and check logs for which template is used; or temporarily change a heading to confirm it’s picked.
|
||||
- **Partials receive data:** Log output with `{{ printf "%#v" .data }}` inside a partial (temporarily) to confirm data structure.
|
||||
- **Data keys match partial expectations:** If a partial expects `.data.items`, ensure `data/homepage.yaml` has `items:` under the right section.
|
||||
- **Minify/fingerprint on production:** Useful for caching; keep `minify = true` and use `fingerprint`.
|
||||
|
||||
---
|
||||
|
||||
If you share a snippet of your current `layouts/index.html`, one sample partial, and the top of `assets/custom.scss`, I can review the wiring and suggest the cleanest way to structure imports for Bulma v1 and your Fresh overrides.
|
||||
|
||||
[^1]: via Hugo Pipes / Dart Sass
|
||||
|
||||
[^2]: In `/layouts/_default/baseof.html`
|
||||
481
iso27DIY content modules.canvas
Normal file
481
iso27DIY content modules.canvas
Normal file
|
|
@ -0,0 +1,481 @@
|
|||
{
|
||||
"nodes":[
|
||||
{"id":"7a48b34c6273cdae","type":"group","x":-460,"y":-580,"width":1720,"height":540,"label":"Context, Strategie en Leiderschap (H4, H5)"},
|
||||
{"id":"09f6d6c1e8efb6e6","type":"group","x":-460,"y":1080,"width":1160,"height":620,"label":"Beleid voor Uitvoering (H8)"},
|
||||
{"id":"6110ac3efe0e4494","type":"group","x":-460,"y":560,"width":1160,"height":400,"label":"PDCA voor Risicomanagement met de Canvas Methode (H8.2, H8.3)"},
|
||||
{"id":"07178dd4253722ab","type":"group","x":-460,"y":80,"width":1160,"height":360,"label":"Risico's en Maatregelen (H6)"},
|
||||
{"id":"288cd10d35aa383a","type":"group","x":300,"y":1800,"width":400,"height":360,"label":"Evaluatie en Verbetering (H9, H10)"},
|
||||
{"id":"1520dd2bd87611ec","type":"group","x":-80,"y":1800,"width":339,"height":360,"label":"Documentatie (H7.5)"},
|
||||
{"id":"1cd9769688fd69c3","type":"group","x":-460,"y":1800,"width":330,"height":360,"label":"Ondersteuning (H7.1-4)"},
|
||||
{
|
||||
"id":"a36ad925134021b2",
|
||||
"type":"text",
|
||||
"text":"Management Workshop\n(H7.3, A6.3, A6.9)",
|
||||
"styleAttributes":{},
|
||||
"x":320,
|
||||
"y":-440,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"53437152acfbfaa1",
|
||||
"type":"text",
|
||||
"text":"Planning Maatregelen (H8.1)",
|
||||
"styleAttributes":{},
|
||||
"x":320,
|
||||
"y":330,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"f967f99a6d088039",
|
||||
"type":"text",
|
||||
"text":"Rollen en Verantw.heden (A5.2-5.4)",
|
||||
"styleAttributes":{},
|
||||
"x":-50,
|
||||
"y":330,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"82679ef2d10465f6",
|
||||
"type":"text",
|
||||
"text":"Asset Inventarisatie (A5.9)",
|
||||
"styleAttributes":{},
|
||||
"x":320,
|
||||
"y":110,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"4c92dc5b2f76a9a5",
|
||||
"type":"text",
|
||||
"text":"Risicoinventarisatie (H6.1.2)",
|
||||
"styleAttributes":{},
|
||||
"x":-50,
|
||||
"y":110,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"872cfd9071333367",
|
||||
"type":"text",
|
||||
"text":"Risicoanalyse (H6.1.2)",
|
||||
"styleAttributes":{},
|
||||
"x":-50,
|
||||
"y":220,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"4db47e26ac77f040",
|
||||
"type":"text",
|
||||
"text":"Penetratie test (A5.35, A8.8)",
|
||||
"styleAttributes":{
|
||||
"textAlign":null
|
||||
},
|
||||
"x":-420,
|
||||
"y":220,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"90146875843a9610",
|
||||
"type":"text",
|
||||
"text":"Dataclassificatie (A5.12)",
|
||||
"styleAttributes":{},
|
||||
"x":320,
|
||||
"y":220,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"40e49243a6b68dcb",
|
||||
"type":"text",
|
||||
"text":"Identificeren Maatregelen (H6.1.3)",
|
||||
"styleAttributes":{},
|
||||
"x":-420,
|
||||
"y":330,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"464dfc9a3def80c2",
|
||||
"type":"text",
|
||||
"text":"Dreigingsanalyse (A5.7)",
|
||||
"styleAttributes":{},
|
||||
"x":700,
|
||||
"y":-240,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"a3402198a7fa4e49",
|
||||
"type":"text",
|
||||
"text":"Bedrijfsprocessen (H4.1)",
|
||||
"styleAttributes":{},
|
||||
"x":-50,
|
||||
"y":-240,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"763fb2036c5dbdde",
|
||||
"type":"text",
|
||||
"text":"DESTEP analyse (H4.2)",
|
||||
"styleAttributes":{},
|
||||
"x":-50,
|
||||
"y":-340,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"6a322f5cf5bd3f6a",
|
||||
"type":"text",
|
||||
"text":"Informatiebeveiligingsbeleid (H5.2)",
|
||||
"styleAttributes":{},
|
||||
"x":320,
|
||||
"y":-540,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"02dc132cd2ef129d",
|
||||
"type":"text",
|
||||
"text":"Organogram (H4.1)",
|
||||
"styleAttributes":{},
|
||||
"x":320,
|
||||
"y":-240,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"39689fc26569c699",
|
||||
"type":"text",
|
||||
"text":"Besturingsmodel (H4.1)",
|
||||
"styleAttributes":{},
|
||||
"x":-50,
|
||||
"y":-440,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"0b7306dec1c85f8d",
|
||||
"type":"text",
|
||||
"text":"Stakeholder analyse (H4.2)",
|
||||
"styleAttributes":{},
|
||||
"x":320,
|
||||
"y":-340,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"f0b8fe39fe16ba4e",
|
||||
"type":"text",
|
||||
"text":"Bepalen Scope (H4.3)",
|
||||
"styleAttributes":{},
|
||||
"x":-50,
|
||||
"y":-540,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"4d7c1e2e9e3b5995",
|
||||
"type":"text",
|
||||
"text":"Wet- en Regelgeving\n(H4.2, A5.31-A5.34)",
|
||||
"styleAttributes":{},
|
||||
"x":700,
|
||||
"y":-340,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"549f8f6976e2591a",
|
||||
"type":"text",
|
||||
"text":"Documentatie (H7.5.2)",
|
||||
"styleAttributes":{},
|
||||
"x":-60,
|
||||
"y":1840,
|
||||
"width":280,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"c8f64dbe95f776d2",
|
||||
"type":"text",
|
||||
"text":"Planning ISMS (H6.1.1)",
|
||||
"styleAttributes":{"textAlign":"center"},
|
||||
"x":-420,
|
||||
"y":-140,
|
||||
"width":1080,
|
||||
"height":60
|
||||
},
|
||||
{
|
||||
"id":"047bf657e7c0381f",
|
||||
"type":"text",
|
||||
"text":"Functiehuis (H4.1)",
|
||||
"styleAttributes":{},
|
||||
"x":-420,
|
||||
"y":-240,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"1f0798149501d740",
|
||||
"type":"text",
|
||||
"text":"Bepalen Doelstellingen (H6.2)",
|
||||
"styleAttributes":{},
|
||||
"x":-420,
|
||||
"y":-540,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"2706559829c7a060",
|
||||
"type":"text",
|
||||
"text":"Risicobereidheid (H6.1.2)",
|
||||
"styleAttributes":{},
|
||||
"x":-420,
|
||||
"y":-440,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"41e3b0bc38d8de84",
|
||||
"type":"text",
|
||||
"text":"SWOT analyse (H4.1)",
|
||||
"styleAttributes":{},
|
||||
"x":-420,
|
||||
"y":-340,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"a2d22052ff7096c5",
|
||||
"type":"text",
|
||||
"text":"Review kalender (H7.5.2)",
|
||||
"styleAttributes":{},
|
||||
"x":-60,
|
||||
"y":1940,
|
||||
"width":280,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"0968542472225677",
|
||||
"type":"text",
|
||||
"text":"Communicatieplan (H7.4)",
|
||||
"styleAttributes":{},
|
||||
"x":-60,
|
||||
"y":2040,
|
||||
"width":280,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"273d40cfef57c393",
|
||||
"type":"text",
|
||||
"text":"Audits en Reviews (H9.2, A.5.35-36)",
|
||||
"styleAttributes":{},
|
||||
"x":320,
|
||||
"y":1840,
|
||||
"width":280,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"28b11a96eef5c2b0",
|
||||
"type":"text",
|
||||
"text":"Management Review (H9.3)",
|
||||
"styleAttributes":{},
|
||||
"x":320,
|
||||
"y":1940,
|
||||
"width":280,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"0a5dc3ad69ffafc2",
|
||||
"type":"text",
|
||||
"text":"Beschikbaarstellen Middelen (H7.1)",
|
||||
"styleAttributes":{},
|
||||
"x":-440,
|
||||
"y":1840,
|
||||
"width":280,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"1e34a0d420b8cfcd",
|
||||
"type":"text",
|
||||
"text":"Competenties (H7.2)",
|
||||
"styleAttributes":{},
|
||||
"x":-440,
|
||||
"y":1940,
|
||||
"width":280,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"13dcb395f4d8f739",
|
||||
"type":"text",
|
||||
"text":"Afwijkingen en Correcties (H10.1)",
|
||||
"styleAttributes":{},
|
||||
"x":320,
|
||||
"y":2040,
|
||||
"width":280,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"68a6efa1a776c676",
|
||||
"type":"text",
|
||||
"text":"Fysieke beveiliging\n(A7.1-7.8, 7.12)",
|
||||
"styleAttributes":{},
|
||||
"x":-40,
|
||||
"y":1445,
|
||||
"width":340,
|
||||
"height":90
|
||||
},
|
||||
{
|
||||
"id":"6273a5aafc2f54d2",
|
||||
"type":"text",
|
||||
"text":"ICT Beheer (A8.7-8.35)",
|
||||
"styleAttributes":{},
|
||||
"x":320,
|
||||
"y":1445,
|
||||
"width":340,
|
||||
"height":90
|
||||
},
|
||||
{
|
||||
"id":"360024c970e70d34",
|
||||
"type":"text",
|
||||
"text":"Implementatie maatregelen (H8.3)",
|
||||
"styleAttributes":{"textAlign":"center"},
|
||||
"x":-40,
|
||||
"y":1565,
|
||||
"width":700,
|
||||
"height":90
|
||||
},
|
||||
{
|
||||
"id":"79a0be9c6f598831",
|
||||
"type":"text",
|
||||
"text":"Leveranciersmanagement (A5.19-A5.23, A8.29)",
|
||||
"styleAttributes":{},
|
||||
"x":320,
|
||||
"y":1344,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"314b04a8959f6fb5",
|
||||
"type":"text",
|
||||
"text":"Device management\n(A7.9-7.10, A8.1, 8.7)",
|
||||
"styleAttributes":{},
|
||||
"x":-420,
|
||||
"y":1445,
|
||||
"width":340,
|
||||
"height":90
|
||||
},
|
||||
{
|
||||
"id":"4184e9e168fd5fdf",
|
||||
"type":"text",
|
||||
"text":"Beleid overige maatregelen (A5.1)",
|
||||
"styleAttributes":{},
|
||||
"x":-420,
|
||||
"y":1565,
|
||||
"width":340,
|
||||
"height":90
|
||||
},
|
||||
{
|
||||
"id":"eaa3c32d191b350e",
|
||||
"type":"text",
|
||||
"text":"Personeelsbeleid\n(A6.1-6.6)",
|
||||
"styleAttributes":{},
|
||||
"x":-420,
|
||||
"y":1235,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"d5be08d2d1baa414",
|
||||
"type":"text",
|
||||
"text":"Toegangsbeleid\n(A5.15-18, A8.2-5)",
|
||||
"styleAttributes":{},
|
||||
"x":-420,
|
||||
"y":1344,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"94c365431ffd100e",
|
||||
"type":"text",
|
||||
"text":"Bewustzijn en training\n(H7.3, A6.3)",
|
||||
"styleAttributes":{},
|
||||
"x":320,
|
||||
"y":1235,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"853301ab7242b5ef",
|
||||
"type":"text",
|
||||
"text":"Gebruikersbeleid\n(A5.10-14, A5.37, A5.40, A6.7-6.8, A7.7, A8.24)",
|
||||
"styleAttributes":{},
|
||||
"x":-40,
|
||||
"y":1235,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"572c91765b41f7f3",
|
||||
"type":"text",
|
||||
"text":"Selectie en implementatie van technologie (A5.8, A5.23, A8.26-33, A.5.38-39, A7.13-14)",
|
||||
"styleAttributes":{},
|
||||
"x":-40,
|
||||
"y":1344,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{"id":"6c394a4088d586b3","type":"file","file":"📎 Attachments/Canvas Cyclus.png","x":382,"y":620,"width":278,"height":200},
|
||||
{
|
||||
"id":"1e6b25bf6dcb833e",
|
||||
"type":"text",
|
||||
"text":"Bedrijfscontinuïteitsplan (A5.29-5.30, A5.42, A7.11)",
|
||||
"styleAttributes":{},
|
||||
"x":320,
|
||||
"y":1120,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"d3b8c88bc841e209",
|
||||
"type":"text",
|
||||
"text":"Business Impact Analyse (A5.29-5.30)",
|
||||
"styleAttributes":{},
|
||||
"x":-40,
|
||||
"y":1120,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"ff8f4d59b9462109",
|
||||
"type":"text",
|
||||
"text":"Incidentenbeheer \n(A5.24-29, A5.43, A6.8)",
|
||||
"styleAttributes":{},
|
||||
"x":-420,
|
||||
"y":1120,
|
||||
"width":340,
|
||||
"height":80
|
||||
},
|
||||
{
|
||||
"id":"8cf31932e32c4d1c",
|
||||
"type":"text",
|
||||
"text":"Continue verbetering (H10.1)",
|
||||
"styleAttributes":{"textAlign":"center"},
|
||||
"x":-408,
|
||||
"y":880,
|
||||
"width":1068,
|
||||
"height":60
|
||||
},
|
||||
{"id":"ddfc9917c2c7fc66","type":"file","file":"📎 Attachments/Canvas Cyclus.png","x":-408,"y":620,"width":278,"height":200},
|
||||
{"id":"27d02011ccccb4c0","type":"file","file":"📎 Attachments/Canvas Cyclus.png","x":-19,"y":620,"width":278,"height":200}
|
||||
],
|
||||
"edges":[],
|
||||
"metadata":{
|
||||
"version":"1.0-1.0",
|
||||
"frontmatter":{}
|
||||
}
|
||||
}
|
||||
63
iso27DIY-mkII-MoC.md
Normal file
63
iso27DIY-mkII-MoC.md
Normal file
|
|
@ -0,0 +1,63 @@
|
|||
---
|
||||
tags:
|
||||
- project/iso27DIY
|
||||
- type/MoC
|
||||
---
|
||||
## Marketing source material
|
||||
[[ISO27DIY Solution and Components]]
|
||||
[[Value Proposition Canvas for iso27DIY]]
|
||||
[[Brand Values]]
|
||||
[[FUD with Certification]]
|
||||
[[PRD Product Requirements Document for iso27DYI]]
|
||||
|
||||
[[iso27DIY Functional Diagram.canvas|iso27DIY Functional Diagram]]
|
||||
[[iso27DIY content modules.canvas|iso27DIY content modules]]
|
||||
|
||||
## Marketing
|
||||
|
||||
[[The Psychology Behind SaaS Pricing|Pricing]]
|
||||
[[Pricing Tiers for iso27DIY|Tiers]]
|
||||
[[SEO guide for Carrd|Website SEO]]
|
||||
[[Idea Validation]]
|
||||
|
||||
## Method
|
||||
[[Samenhang tussen producten]]
|
||||
[[ISO 27001 2023 Processen en Artefacten]]
|
||||
[[Advised Documents for ISO 27001]]
|
||||
[[Examples of Proof for auditors]]
|
||||
[[About ISO27DIY Policy Cards]]
|
||||
|
||||
## Design
|
||||
[[ISO27DIY als LMS]]
|
||||
[[iso27DIY content modules.canvas|Modules Canvas]]
|
||||
[[About the flow]]
|
||||
[[iso27DIY UI ideas|UI ideas]]
|
||||
|
||||
### Agents
|
||||
[[Create a proactive conversational agent]]
|
||||
[[Create an interview agent]]
|
||||
[[Agent Design Intent Card]]
|
||||
[[Create a threat analysis chatbot]]
|
||||
[[Instruct an LLM on available tools]]
|
||||
[[LLM Prompt types]]
|
||||
|
||||
|
||||
## Content
|
||||
[[ISO27DIY Videos list]]
|
||||
|
||||
## Platform
|
||||
[[Ontwikkelplan]]
|
||||
[[Design Document for ISO 27001 Certification Support Online Service]]
|
||||
[[iso27DIY Customer Journey]]
|
||||
[[Personae and Roles]]
|
||||
[[TypeDB structure for ISO27DIY]]
|
||||
[[Client segregation]]
|
||||
[[Building functionality in Supabase]]
|
||||
[[SupaBase edge functions portability]]
|
||||
[[Connect LLM to Supabase to create content]]
|
||||
[[Deciding which functionality goes where]]
|
||||
[[iso27DYI architecture with LLM]]
|
||||
[[iso27DIY stack deployment]]
|
||||
[[SurveyJS]]
|
||||
[[weweb_security_checklist|WeWeb Security Pre-Launch Checklist]]
|
||||
|
||||
BIN
marketing/.DS_Store
vendored
Normal file
BIN
marketing/.DS_Store
vendored
Normal file
Binary file not shown.
23
marketing/Channels.md
Normal file
23
marketing/Channels.md
Normal file
|
|
@ -0,0 +1,23 @@
|
|||
# Marketing Channels
|
||||
|
||||
## Devs
|
||||
|
||||
https://www.producthunt.com/@richardk3000/
|
||||
|
||||
https://indieapps.space/about
|
||||
https://www.indiehackers.com/
|
||||
|
||||
https://news.ycombinator.com
|
||||
|
||||
https://www.reddit.com/r/startups/s/YgLLCUwCYA
|
||||
|
||||
https://www.reddit.com/r/ycombinator/s/LScdyyPYCm
|
||||
|
||||
## MSP’s
|
||||
[Fortmesa](https://mail.fortmesa.com/meetings/lgarciarizo/webinar-pre-call?utm_campaign=Activation+Marketplace+Success&utm_medium=email&_hsenc=p2ANqtz-9twPh0MxTZ9c55kreLj_tPiN7VdUDG0C4l0DEbicx2sKqIYc-HlgZ1myRX3ridWtZkfngU3PkrYK1lO9yp06Bo3VPIk_0WWrkYmTbI7FLkOYc6X_o&_hsmi=327323725&utm_content=327323725&utm_source=hs_automation&uuid=6dd12501-109c-4e63-ab8c-2533b5c4075b)
|
||||
## SME’s
|
||||
[NCSC Community](https://digitaltrustcommunity.nl)
|
||||
## Auditors
|
||||
ISACA
|
||||
NOREA
|
||||
|
||||
65
marketing/automation/UTM coding scheme.md
Normal file
65
marketing/automation/UTM coding scheme.md
Normal file
|
|
@ -0,0 +1,65 @@
|
|||
# UTM coding scheme
|
||||
*overzicht xlsx onderaan deze note*
|
||||
|
||||
Alle waarden: **lowercase**, **koppeltekens** als scheidingsteken, geen spaties.
|
||||
## utm_source — kanaal
|
||||
|
||||
| Waarde | Kanaal |
|
||||
| -------------- | ------------------ |
|
||||
| `linkedin` | LinkedIn |
|
||||
| `reddit` | Reddit |
|
||||
| `newsletter` | E-mail nieuwsbrief |
|
||||
| `devto` | Dev.to |
|
||||
| `hashnode` | Hashnode |
|
||||
| `producthunt` | Product Hunt |
|
||||
| `indiehackers` | Indie Hackers |
|
||||
|
||||
## utm_medium — type uiting
|
||||
|
||||
| Waarde | Type |
|
||||
|--------|------|
|
||||
| `article` | Lang artikel of post |
|
||||
| `post` | Korte post of update |
|
||||
| `comment` | Comment of reactie |
|
||||
| `bio` | Profiel- of biolink |
|
||||
| `ad` | Betaalde advertentie |
|
||||
|
||||
## utm_campaign — thema + kwartaal
|
||||
|
||||
| Waarde | Omschrijving |
|
||||
|--------|-------------|
|
||||
| `iso27001-basics-q2-2026` | ISO 27001 basics — Q2 2026 |
|
||||
| `smb-compliance-q2-2026` | MKB compliance — Q2 2026 |
|
||||
| `tool-launch-q2-2026` | Tool/template lancering — Q2 2026 |
|
||||
| `evergreen` | Altijd-actieve links (bio, profiel) |
|
||||
|
||||
## utm_content — specifieke CTA
|
||||
|
||||
| Waarde | CTA |
|
||||
|--------|-----|
|
||||
| `cta-signup` | Primaire CTA — aanmelden / gratis proberen |
|
||||
| `cta-download` | Tool of template downloaden |
|
||||
| `cta-read` | Artikel lezen |
|
||||
| `cta-home` | Homepage link |
|
||||
| `cta-inpost` | Link in de post zelf |
|
||||
| `cta-comment` | Link in een comment |
|
||||
|
||||
## VoorbeeldURLs
|
||||
|
||||
```
|
||||
# LinkedIn bio (evergreen)
|
||||
https://iso27diy.com/?utm_source=linkedin&utm_medium=bio&utm_campaign=evergreen&utm_content=cta-home
|
||||
|
||||
# LinkedIn artikel — signup CTA
|
||||
https://iso27diy.com/signup?utm_source=linkedin&utm_medium=article&utm_campaign=iso27001-basics-q2-2026&utm_content=cta-signup
|
||||
|
||||
# Reddit comment
|
||||
https://iso27diy.com/?utm_source=reddit&utm_medium=comment&utm_campaign=smb-compliance-q2-2026&utm_content=cta-comment
|
||||
|
||||
# Newsletter — tool download
|
||||
https://iso27diy.com/tools?utm_source=newsletter&utm_medium=article&utm_campaign=tool-launch-q2-2026&utm_content=cta-download
|
||||
```
|
||||
|
||||
## UTM overzicht
|
||||
|
||||
![[utm-tracker.xlsx]]
|
||||
21
marketing/automation/UTM-tracking.md
Normal file
21
marketing/automation/UTM-tracking.md
Normal file
|
|
@ -0,0 +1,21 @@
|
|||
## UTM-parameters
|
||||
|
||||
UTM = Urchin Tracking Module, vernoemd naar een webanalytics bedrijf dat Google in 2005 opkocht.
|
||||
### Hoe het werkt
|
||||
|
||||
Je plakt parameters achter elke link, bijvoorbeeld:
|
||||
|
||||
```
|
||||
https://jouwsite.nl/pagina?utm_source=linkedin&utm_medium=post&utm_campaign=launch&utm_content=cta-button
|
||||
```
|
||||
|
||||
De standaard parameters:
|
||||
|
||||
- `utm_source` — waar komt het vandaan? (linkedin, reddit, hackernews)
|
||||
- `utm_medium` — wat voor type uiting? (post, bio, comment, newsletter)
|
||||
- `utm_campaign` — welke campagne/periode? (launch-v1, april2025)
|
||||
- `utm_content` — welke specifieke CTA of variant? (cta-hero, cta-footer, cta-gratis-demo)
|
||||
- `utm_term` — oorspronkelijk gebruikt voor betaalde zoekopdrachten om bij te houden op welk zoekwoord iemand klikte
|
||||
|
||||
Daarbuiten kun je in principe eigen parameters verzinnen — sommige tools ondersteunen dat, Umami werkt alleen met de vijf standaard parameters.
|
||||
|
||||
16
marketing/branding/ISO27DIY Website color scheme.md
Normal file
16
marketing/branding/ISO27DIY Website color scheme.md
Normal file
|
|
@ -0,0 +1,16 @@
|
|||

|
||||
|
||||

|
||||
|
||||
|
||||
| **Grid type** | $grid-size | $bg-size | $grid-opacity | **Gradient** |
|
||||
|:-:|:-:|:-:|:-:|:-:|
|
||||
| Dot grid (Moleskine) | 1px | 20px 20px | 0.06 | 1× radial |
|
||||
| Fine dot grid | 1px | 5px 5px | 0.04 | 1× radial |
|
||||
| Engineering paper | 1px | 4px 4px | 0.05 | 2× linear |
|
||||
| Graph paper (fine) | 1px | 10px 10px | 0.06 | 2× linear |
|
||||
| Graph paper (standard) | 1px | 20px 20px | 0.08 | 2× linear |
|
||||
| Architectural (open) | 1px | 40px 40px | 0.12 | 2× linear |
|
||||
| Engineering (major+minor) | 1px | 4px 4px + 20px 20px | 0.04 + 0.10 | 4× linear |
|
||||
The last row needs four gradients — two for the minor grid at low opacity, two for the major grid at higher opacity, all stacked in one background-image declaration.
|
||||
|
||||
37
marketing/campaigns/Brand Values.md
Normal file
37
marketing/campaigns/Brand Values.md
Normal file
|
|
@ -0,0 +1,37 @@
|
|||
# iso27DIY Brand values
|
||||
|
||||
Primary:
|
||||
* **A**uthenticity
|
||||
* **C**larity
|
||||
* **E**mpowerment
|
||||
|
||||
Secondary:
|
||||
* Value Creation
|
||||
* Organizational Alignment
|
||||
* Context-Driven Intelligence
|
||||
* Practicality Over Bureaucracy
|
||||
* Inclusivity
|
||||
|
||||
## Based on: Our thoughts and beliefs on current practices
|
||||
|
||||
I created iso27DIY because I think / believe …
|
||||
- The core principles of the ISO 27001 are often overlooked in implementations and audits. These are that, when implementing the ISO 27001’s ISMS and Controls, informed decisions should be made based on risks, context, and the means and capabilities of the organization.
|
||||
- Furthermore, the ISMS must be implemented in such a way that it is helpful in realizing organizational goals, mitigates risks the organizations faces in achieving these, and promote seizing opportunities, especially with regard to information security.
|
||||
- Current implementation approaches take the letter of the standard instead of the spirit, and force the business into adapting overly complex procedures and building an artificial paper reality.
|
||||
- ISO 27001 is a Framework, not a prescriptive checklist.
|
||||
- Checklist-based approaches are not effective, because they lack internal cohesion, connection to organizationals goals, risk- and context awareness. They do not implement security in a way that contributes to an organization’s mission and negate the organization’s capabilities for making intelligent choices based on context, risk and proportionality.
|
||||
- This makes ISO 27001 impopular with management and workfloor, causing it to become ineffective.
|
||||
- The language and structure of the ISO 27001 standard is hard to comprehend because of the formalistic language, internal cross references, and duplications of elements at different levels. This creates a certain mystique that forces organizations to hire a ‘priest’ (i.e. consultant) to help them understand what to do.
|
||||
- SMEs think they lack adequate time, trained personnel, and budget to manage the implementation process effectively
|
||||
|
||||
## The ISO27DIY way
|
||||
|
||||
- iso27DIY tells the story of ISO 27001 and 27002 in such a way, that you will understand the essence of the standard, and are able to make informed and compliant choices based on context, risk and proportionality.
|
||||
- iso27DIY helps you identify security practices already in place in your organization, and enhance, translate and document them in such a way that comliance requirements are met. (‘control mapping’)
|
||||
- iso27DIY lets you implement the ISMS and controls in such a way that they actually improve the organization’s security posture, create value at all levels of the organization, and create a culture of security.
|
||||
- iso27DIY does not force you to adopt contra-productive security procedures and maintain unnecessary documentation.
|
||||
- We believe in your capability to do it yourself!
|
||||
|
||||
|
||||
|
||||
|
||||
47
marketing/campaigns/FUD with Certification.md
Normal file
47
marketing/campaigns/FUD with Certification.md
Normal file
|
|
@ -0,0 +1,47 @@
|
|||
# Fears, Uncertainties, and Doubts with ISO 27001 certification
|
||||
|
||||
People who need to implement ISO 27001 within their organization, often worry about the following:
|
||||
|
||||
* Am I doing it right
|
||||
* Did I interpret this article correctly
|
||||
* Haven’t I forgotten anything
|
||||
* Are we doing enough
|
||||
* How long will this take
|
||||
* How will I get people to cooperate
|
||||
* This will bring a mound of unnecessary paperwork
|
||||
* We will need to implement unworkable procedures
|
||||
* This will take all flexibility out of our way of working
|
||||
* We will become robots
|
||||
* We will need to implement all kind of expensive measures
|
||||
|
||||
## Themes
|
||||
|
||||
The challenges they face an be grouped in several themes, as described below.
|
||||
|
||||
**Lack of leadership / top management support**
|
||||
- leadership doesn't fully understand the value of ISO 27001, sees it as a bureaucratic burden instead of a strategic priority
|
||||
- not a priority for middle management because of leadership stance
|
||||
- lack of resource allocation (time, money and people) due to lack of leadership
|
||||
|
||||
**Business alignment**
|
||||
- overly long and confusing policies that are difficult for employees to understand and auditors to navigate
|
||||
- Risk of ISMS becoming isolated from real business processes, especially when internal responsibility lies with people lacking authority or visibility into all business areas.
|
||||
* integration of management processes, process documentation, and continuous evaluation
|
||||
|
||||
**Acceptance / buy in at operational level:**
|
||||
- (cultural) resistance from employees, beccause ISO 27001 implementation often introduces new policies and processes that can be perceived as burdensome or unnecessary
|
||||
- this is aggravated if staff don't understand the benefits and/or aren't properly trained
|
||||
- this is aggravated if the ISMS is implemented as, or perceived as, an artificial system for certification rather than an integrated part of the company's culture and operations
|
||||
|
||||
**Documentation /policy tuning:**
|
||||
- how to create and maintaining policies and procedures that are both comprehensive enough to satisfy auditors and practical enough for employees to follow.
|
||||
- Over-engineering of a one-size-fits-all approach from templates, leading to massive, unwieldy documents, instead of tailoring the documentation to the specific needs and size of the organization
|
||||
- finding the balance between being thorough and being concise – how much detail or separation is appropriate for policies, procedures, and supporting documentation
|
||||
|
||||
**On Risks:**
|
||||
- How do we properly identify, analyze, and prioritize all relevant risks.
|
||||
- Fear of missing a critical risk or not prioritizing them correctly.
|
||||
|
||||
**Passing the audit:**
|
||||
- When is a control implemented "enough" to pass an audit and a fear of misinterpreting the auditor's expectations. This often stems from the fact that ISO 27001 is a framework, not a prescriptive checklist.
|
||||
- Lack of structured and impartial internal audit processes
|
||||
31
marketing/campaigns/ISO27DIY Solution and Components.md
Normal file
31
marketing/campaigns/ISO27DIY Solution and Components.md
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
# ISO27DIY: Solution and Components
|
||||
|
||||
We are developing a solution for SME’s that will guide them through the ISO 27001 implementation, and prepare for a successful certification audit, without needing to hire expensive consultants. The solution is called ISO27DIY.
|
||||
|
||||
These are the **components** of the solution:
|
||||
|
||||
- **ISO27DYI Guided Implementation System**: A series of 50+ micro sessions take you through the steps to successfully implement ISO 27001, creating all required documentation as you go. Use our AI assistent to generate tailor made information security policies.
|
||||
- **GRC Tooling**: Our easy to use AuditGlue system lets you manage all artifacts produced with the Guided Implementation. Plus tooling for stuff like risk analyses, data classification and asset inventarization.
|
||||
- **Controls Library**: Practical examples for your type of organization, for all 94 controls of Annex A, actionable and in Plain English.
|
||||
- **Expert Support**: Get online with one of our experienced ISO 27001 implementation consultants to help you find a solution for any challenges you might face.
|
||||
- **Preliminary audits**: Plan one or more sessions with certified ISO 27001 auditors to prepare you for your certification.
|
||||
|
||||
These are the **design principles** for the solution:
|
||||
|
||||
- The customer is typically an SME, with no dedicated compliance officer and little knowledge of information security management and the ISO 27001 standard.
|
||||
- The user of the solution is the person made responsible for implementing the ISO 27001 standard within the SME. He or she is typically employed as the ‘Tech person’ or the COO.
|
||||
- iso27DIY guides the client in what to identify, assess and produce, how to do it, and in what order
|
||||
- iso27DYI's guidance will feel like a smartwatch fitness coach, rather than having the user walking down checklists
|
||||
- iso27DIY provides best practice examples and generates compliant content based on the user's input
|
||||
- iso27DYI will help the client with building the necessary capabilities to maintain the ISMS within his own organization
|
||||
|
||||
## Components in a table
|
||||
|
||||
| Guided Implementation | **Controls Library** | GRC Tooling |
|
||||
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| A series of 50+ micro sessions take you through the steps to succesfully implement ISO 27001, creating all required documentation as you go. Use our AI assistent to generate tailor made information security policies. | Practical examples for your type of organization, for all 94 controls of Annex A, actionable and in Plain English. | Our easy to use AuditGlue system lets you manage all artifacts produced with the Guided Implementation. Plus tooling for stuff like risk analyses, data classification and asset inventarization. |
|
||||
|
||||
| **Expert Support** | **Preliminary audits** |
|
||||
| ------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------- |
|
||||
| Get online with one of our experienced ISO 27001 implementation consultants to help you find a solution for any challenges you might face. | Plan one or more sessions with certified ISO 27001 auditors to prepare you for your certification. |
|
||||
|
||||
46
marketing/campaigns/ISO27DIY communication style.md
Normal file
46
marketing/campaigns/ISO27DIY communication style.md
Normal file
|
|
@ -0,0 +1,46 @@
|
|||
# Communication Style Guide
|
||||
|
||||
## Voice and tone
|
||||
|
||||
Direct, confident, and plain-spoken. No corporate jargon. No filler. Every word earns its place. The tone is authoritative without being academic, and human without being casual.
|
||||
|
||||
## Sentence structure
|
||||
|
||||
Short sentences are preferred. Long sentences are broken up. Parallelism is used deliberately — three-part structures work well when each part carries equal weight. Fragments are acceptable when they land a point cleanly.
|
||||
|
||||
## Word choices
|
||||
|
||||
- Prefer concrete over abstract
|
||||
- Prefer active over passive
|
||||
- Prefer simple over sophisticated
|
||||
- "Effective" over "impactful"
|
||||
- "Enables" over "empowers"
|
||||
- "Adapt" and "adaptive" over "dynamic" or "agile"
|
||||
- Avoid: "leverage", "synergy", "holistic", "seamless", "robust"
|
||||
|
||||
## What to avoid
|
||||
|
||||
- Negative framing — state what good looks like, not what bad looks like
|
||||
- Accusatory or confrontational language — invite people to something better rather than criticising what they do now
|
||||
- Over-explanation — trust the reader
|
||||
- Hedging — commit to the statement
|
||||
- Bullet points where prose works better
|
||||
|
||||
## Manifesto-style writing specifically
|
||||
|
||||
- Value statements follow the "X over Y" format — both sides should name real things people recognise
|
||||
- The right-hand side is not villainised — it has value, it just comes second
|
||||
- Principles are short, declarative, and standalone — each one a truth that can be read in isolation
|
||||
- Forward-leaning and positive — declare what good looks like
|
||||
- Aphoristic where possible — aim for sentences that could be quoted
|
||||
|
||||
## The reader
|
||||
|
||||
The audience is entrepreneurs and business managers implementing ISO 27001 themselves. They are intelligent, pragmatic, and time-poor. They are put off by complexity and consultant-speak. They respond to clarity, honesty, and respect for their intelligence.
|
||||
|
||||
## Editing instincts
|
||||
|
||||
- If two sentences say the same thing, cut one
|
||||
- If a word is ambiguous, replace it
|
||||
- If a sentence trails off, find a stronger closing beat
|
||||
- If something sounds like it came from a brochure, rewrite it
|
||||
20
marketing/campaigns/Personal Writing Style.md
Normal file
20
marketing/campaigns/Personal Writing Style.md
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
## Writing Style — Richard / ISO27DIY
|
||||
|
||||
**Tone** Direct and businesslike, without being cold. You write as someone who has done it themselves and takes the reader seriously. No inflated consultant-speak, no unnecessary politeness buffers.
|
||||
|
||||
**Sentence structure** A preference for short, assertive sentences. You use the long sentence to explain, the short sentence to land the point. Contrast works well for you: "You document upfront — this is how we'll do it — and afterwards — this is what we did and what it produced."
|
||||
|
||||
**Word choice** No jargon unless necessary, and when used, immediately explained. You use plain terms where possible, but don't shy away from industry-standard terminology (_top management_, _Statement of Applicability_, _risk owner_) where it's the accepted term. No woolly management language — you don't say "suboptimal"; you say "wrong order."
|
||||
|
||||
**Structure** Step-by-step, but never mechanical. Each step has its own logic, which you briefly explain before instructing. You explicitly connect steps to each other ("the context analysis from step 2", "the risk score from step 6") — the reader never loses the thread.
|
||||
|
||||
**Figurative language** Sparing but precise. You choose images and expressions that everyone understands and that address exactly the right objection or expectation — no decoration for its own sake.
|
||||
|
||||
**What you consistently avoid**
|
||||
|
||||
- Rhetorical questions as openers
|
||||
- Meta-commentary ("what I'm trying to say is...")
|
||||
- Repeating the headline in the introduction
|
||||
- False modesty or unnecessary hedging
|
||||
|
||||
**Core character** Clear, honest, mildly opinionated. You are the guide who knows the route — not the consultant trying to impress.
|
||||
20
marketing/campaigns/Persoonlijke Schrijfstijl.md
Normal file
20
marketing/campaigns/Persoonlijke Schrijfstijl.md
Normal file
|
|
@ -0,0 +1,20 @@
|
|||
# Schrijfstijl — Richard / ISO27DIY
|
||||
|
||||
**Toon** Direct en zakelijk, zonder afstandelijkheid. Je schrijft als iemand die het zelf heeft gedaan en de lezer serieus neemt. Geen opgeblazen consultantentaal, geen onnodige beleefdheidsbuffers.
|
||||
|
||||
**Zinsstructuur** Voorkeur voor korte, assertieve zinnen. Je gebruikt de lange zin om uit te leggen, de korte zin om te landen. Contrasten werken goed voor je: "Je documenteert vooraf — zo gaan we het doen, en achteraf — zo hebben we het gedaan."
|
||||
|
||||
**Woordkeus** Geen jargon tenzij noodzakelijk, en dan direct uitgelegd. Je gebruikt Nederlandse termen waar het kan (_directiebeoordeling_, _risico-eigenaar_), maar schroomt niet voor Engels waar het de standaardterm is (_top management_, _Statement of Applicability_). Geen wollige managementtaal — "niet effectief" vervang je door "verkeerde volgorde".
|
||||
|
||||
**Structuur** Stap-voor-stap, maar niet mechanisch. Elke stap heeft een eigen logica die je kort toelicht voordat je instrueert. Je verbindt stappen expliciet aan elkaar ("de contextanalyse uit stap 2", "de risicoscore uit stap 6") — de lezer verliest nooit het overzicht.
|
||||
|
||||
**Beeldtaal** Spaarzaam maar raak. Zevenmijlslaarzen, rocket science, formulierenwinkel — je kiest beelden die iedereen begrijpt en die precies het juiste bezwaar of de juiste verwachting adresseren.
|
||||
|
||||
**Wat je consequent vermijdt**
|
||||
|
||||
- Retorische vragen als opener
|
||||
- Meta-commentaar ("wat ik wil zeggen is...")
|
||||
- Herhalingen van de kop in de inleiding
|
||||
- Valse bescheidenheid of onnodige relativering
|
||||
|
||||
**Kernkarakter** Helder, eerlijk, licht eigenzinnig. Je bent de gids die de route kent, niet de consultant die indruk wil maken.
|
||||
41
marketing/campaigns/Taglines and Payoffs.md
Normal file
41
marketing/campaigns/Taglines and Payoffs.md
Normal file
|
|
@ -0,0 +1,41 @@
|
|||
Current:
|
||||
* Certification shouldn't be a barrier to competition.
|
||||
- Guided ISO 27001 implementation. No consulting required.
|
||||
- ISO27DIY: Get Certified – Keep Growing
|
||||
|
||||
# Taglines
|
||||
|
||||
* ISO 27001. **Mastered**.
|
||||
* You've got this. We'll show you how.
|
||||
* ISO 27001 for All!
|
||||
* Make your auditor happy
|
||||
* Implementing ISO 27001 is no Rocket Science ... but the manual can be darn confusing!
|
||||
* ISO 27001 used to be Rocket Science … until we rewrote the manual
|
||||
- Certify Smarter
|
||||
- **The Smart path to ISO 27001 certification**
|
||||
- We simplify ISO 27001 compliance
|
||||
- ISO 27001 made Easy
|
||||
- ISO 27001: Why make it difficult?
|
||||
|
||||
- **We help SMEs secure ISO 27001 certification**
|
||||
- We help SMEs prepare for ISO 27001 certification
|
||||
- We get SMEs certification-ready
|
||||
- Navigate through ISO 27001 certification ... Easily
|
||||
- ISO 27001 certification with confidence
|
||||
- Supporting SMEs in achieving ISO 27001 readiness
|
||||
- Streamlining ISO 27001 certification prep for SMEs
|
||||
## Payoff suggestions
|
||||
|
||||
* "Big company security, small company budgets”
|
||||
* "ISO 27001 certification achievable for SMEs"
|
||||
* "Enterprise security, startup agility"
|
||||
* “Enterprise-level security for SME’s
|
||||
* "Security standards for real businesses"
|
||||
* "Compliance that fits your business"
|
||||
* "No organization left behind in cybersecurity"
|
||||
* "Build on what works. Fix what doesn't."
|
||||
* “More security, less consulting”
|
||||
* “Clarity. Not Consultancy.”
|
||||
* “ISO 27001 that makes sense”
|
||||
* "Security standards. Demystified."
|
||||
* "Enterprise security, democratized."
|
||||
123
marketing/campaigns/doelgroepen.md
Normal file
123
marketing/campaigns/doelgroepen.md
Normal file
|
|
@ -0,0 +1,123 @@
|
|||
# Doelgroepen & marktsegmenten — ISO27DIY
|
||||
|
||||
---
|
||||
|
||||
## Segment 1 — Founders & SaaS-bedrijven
|
||||
|
||||
**Profiel**
|
||||
Technische oprichters van software- of SaaS-bedrijven. Ze hebben security serieus genomen, maar niet systematisch. Het ISMS bestaat uit losse tools en documenten, niet als samenhangend managementsysteem.
|
||||
|
||||
**Motief**
|
||||
Enterprise-sales. Een grote klant of aanbesteding stelt ISO 27001 als harde voorwaarde. De certificering is geen overtuiging maar een dealbreaker die ze willen wegnemen — bij voorkeur snel en zonder externe consultant.
|
||||
|
||||
**Trigger**
|
||||
"We verliezen een deal als we dit niet hebben."
|
||||
|
||||
**Boodschap**
|
||||
Je security is waarschijnlijk beter dan je denkt. Wat ontbreekt is de aantoonbaarheid — een managementsysteem dat een auditor kan volgen. Dat is oplosbaar, ook zonder groot budget of consultant.
|
||||
|
||||
**Kanalen**
|
||||
- LinkedIn (eigen netwerk + groepen)
|
||||
- Reddit: r/SaaS, r/ISO27001, r/startups
|
||||
- Hacker News
|
||||
- Nieuwsbrief
|
||||
|
||||
---
|
||||
|
||||
## Segment 2 — MKB-directeuren
|
||||
|
||||
**Profiel**
|
||||
Directeuren van kleine tot middelgrote bedrijven die zelf geen IT-achtergrond hebben. Ze zijn eindverantwoordelijk maar delegeren security aan een IT-beheerder of externe partij. ISO 27001 komt op hun radar via een klant, verzekeraar of aanbesteding.
|
||||
|
||||
**Motief**
|
||||
Zakelijke continuïteit en klantbehoud. De certificering is een investering die ze willen begrijpen — wat kost het, wat levert het op, wat wordt er van hen verwacht?
|
||||
|
||||
**Trigger**
|
||||
"Een opdrachtgever vraagt erom" of "onze verzekeraar stelt strengere eisen."
|
||||
|
||||
**Boodschap**
|
||||
ISO 27001 is geen IT-project — het is een managementsysteem. De directie is er niet de uitvoerder van, maar wél de eindverantwoordelijke. Dit eBook legt uit wat dat concreet betekent, wat het kost, en hoe het proces eruitziet.
|
||||
|
||||
**Kanalen**
|
||||
- LinkedIn
|
||||
- Nieuwsbrief
|
||||
- Google (SEO op "ISO 27001 MKB", "kosten ISO 27001 certificering")
|
||||
|
||||
---
|
||||
|
||||
## Segment 3 — Dienstverleners zonder online kern
|
||||
|
||||
**Profiel**
|
||||
Organisaties die persoonsgegevens of klantdata verwerken, maar zichzelf niet als IT-bedrijf zien. Denk aan kinderopvang, installatietechnici, IoT-leveranciers, facilitaire dienstverleners. Ze worden geconfronteerd met ISO 27001 als eis van een opdrachtgever of in een aanbesteding — terwijl ze zelf nauwelijks weten wat het inhoudt.
|
||||
|
||||
**Motief**
|
||||
Marktoegang. Ze willen aan een specifieke eis voldoen om een contract te winnen of te behouden. De drijfveer is extern, niet intern.
|
||||
|
||||
**Trigger**
|
||||
"Onze opdrachtgever vraagt om een ISO 27001-certificaat. We weten niet waar we moeten beginnen."
|
||||
|
||||
**Boodschap**
|
||||
ISO 27001 is niet alleen voor techbedrijven. Als je persoonsgegevens verwerkt of toegang hebt tot de systemen van je opdrachtgever, ben je al in scope. Dit eBook legt uit wat er van je wordt verwacht — en dat het minder ingewikkeld is dan het klinkt.
|
||||
|
||||
**Kanalen**
|
||||
- Brancheverenigingen en sectormedia (kinderopvang, installatiebranche, IoT/OT)
|
||||
- LinkedIn via branchegroepen
|
||||
- Google (SEO op "ISO 27001 kinderopvang", "ISO 27001 leverancier opdrachtgever", "ISO 27001 niet-IT bedrijf")
|
||||
|
||||
---
|
||||
|
||||
## Segment 4 — Organisaties onder regelgevingsdruk
|
||||
|
||||
**Profiel**
|
||||
Bedrijven die vanuit wet- en regelgeving hun informatiebeveiliging moeten aantonen — denk aan NIS-2, de Cyberbeveiligingswet (Cbw), de Cyber Resilience Act (CRA), of sectorspecifieke eisen. Ze hebben geen expliciete ISO 27001-behoefte, maar zoeken wel een aanpak die hun compliance-last structureel oplost.
|
||||
|
||||
**Motief**
|
||||
Regelgevingsdruk en aansprakelijkheidsreductie. Ze moeten iets doen — en willen niet voor elke nieuwe wet opnieuw het wiel uitvinden.
|
||||
|
||||
**Trigger**
|
||||
"We moeten aan NIS-2 voldoen. Hoe pakken we dat aan zonder voor elke regelgeving een apart traject op te zetten?"
|
||||
|
||||
**Boodschap**
|
||||
ISO 27001 is geen doel op zich — het is een fundament. Een goed ingericht ISMS dekt de kern van wat NIS-2, de Cbw en de CRA van je vragen. Eén systeem, meerdere regelgevingen afgedekt. Dat is efficiënter dan losse compliance-trajecten per wet.
|
||||
|
||||
**Kanalen**
|
||||
- LinkedIn (compliance, legal, risk management doelgroep)
|
||||
- Google (SEO op "NIS-2 ISO 27001", "Cbw informatiebeveiliging", "CRA compliance basis")
|
||||
- Branchemedia en vakbladen (recht, compliance, risk)
|
||||
- Nieuwsbrief
|
||||
|
||||
---
|
||||
|
||||
## Segment 5 — MSP's (Managed Service Providers)
|
||||
|
||||
**Profiel**
|
||||
IT-dienstverleners die het MKB ontzorgen op het gebied van infrastructuur, beheer en security. Ze zijn het eerste aanspreekpunt als een klant een ISO 27001-vraag krijgt — van een opdrachtgever, verzekeraar of aanbesteding. Ze hebben doorgaans zelf geen uitgewerkt ISO 27001-aanbod, maar zien de vraag wel toenemen.
|
||||
|
||||
**Motief**
|
||||
Dienstenpakket uitbreiden en klantbehoud. Een MSP die zijn klant kan helpen met ISO 27001-voorbereiding, bindt die klant en vergroot de omzet per account. ISO27DIY is voor hen geen product dat ze zelf gebruiken, maar één dat ze aanbieden of doorverwijzen — als white label, als partnerproduct, of als referral.
|
||||
|
||||
**Trigger**
|
||||
"Mijn klant heeft ISO 27001 nodig. Ik wil dat kunnen oplossen zonder zelf een compliance-afdeling op te bouwen."
|
||||
|
||||
**Boodschap**
|
||||
Jouw klanten krijgen steeds vaker de vraag naar ISO 27001. Met ISO27DIY kun je die vraag beantwoorden — zonder zelf het wiel uit te vinden. Schaalbaar, gestructureerd, en inzetbaar naast je bestaande dienstverlening.
|
||||
|
||||
**Relatie tot andere segmenten**
|
||||
MSP's zijn geen eindgebruiker maar een distributiekanaal. Via hen bereik je segmenten 2 en 3 — de MKB-directeur en de dienstverlener zonder online kern — op het moment dat de behoefte concreet is en de MSP al vertrouwen heeft opgebouwd.
|
||||
|
||||
**Kanalen**
|
||||
- LinkedIn (IT-channel, MSP-communities)
|
||||
- Vakbladen en events: Channel Connect, MSP Summit, IT-channelmedia
|
||||
- Directe partnerwerving via outreach
|
||||
|
||||
---
|
||||
|
||||
## Overzicht
|
||||
|
||||
| Segment | Primaire trigger | Kernboodschap | Prioriteit kanalen |
|
||||
|---|---|---|---|
|
||||
| Founders / SaaS | Dealbreaker in enterprise-sales | Aantoonbaarheid, niet security | LinkedIn, Reddit, HN |
|
||||
| MKB-directeuren | Klanteis of verzekeraar | Managementsysteem, niet IT-project | LinkedIn, Google |
|
||||
| Dienstverleners zonder online kern | Opdrachtgeverseis | Ook voor niet-IT bedrijven | Branchemedia, Google |
|
||||
| Regelgevingsdruk (NIS-2 / Cbw / CRA) | Wettelijke verplichting | Één fundament, meerdere wetten | LinkedIn, Google, vakbladen |
|
||||
| MSP's | Klant heeft ISO 27001 nodig | Distributiepartner, niet eindgebruiker | LinkedIn, channel-events, outreach |
|
||||
BIN
marketing/content/.DS_Store
vendored
Normal file
BIN
marketing/content/.DS_Store
vendored
Normal file
Binary file not shown.
37
marketing/content/LinkedIn Company Page for iso27DYI.md
Normal file
37
marketing/content/LinkedIn Company Page for iso27DYI.md
Normal file
|
|
@ -0,0 +1,37 @@
|
|||
[LinkedIn Company Page](https://www.linkedin.com/company/iso27diy/about/?viewAsMember=true)
|
||||
|
||||
If you're an SME and need to implement ISO 27001, you don't have the budget
|
||||
|
||||
|
||||
**Implementing ISO 27001 is no Rocket Science.**
|
||||
|
||||
... but the manual can be darn confusing!
|
||||
|
||||
Most SMEs face the same problem: ISO 27001 is becoming the price of entry for serving enterprise customers.
|
||||
If you need to implement on a budget, there's no room for expensive consulting or over-complicated GRC tools.
|
||||
Patching together free resources from the internet takes months you don't have, and template kits give no clue on how to adapt things to your business. And to be honest, no firm has ever become more secure by approaching ISO 27001 as a checkbox exercise.
|
||||
|
||||
**Enter iso27DIY**
|
||||
|
||||
Certification shouldn't be a barrier to competition – that’s why we created iso27DIY.
|
||||
|
||||
What it is:
|
||||
|
||||
**A Guided Implementation System** – 50+ micro-sessions that walk you through the ISO 27001 implementation step-by-step, creating all required documentation as you go. Our AI assistant generates tailored policies, not generic templates.
|
||||
|
||||
**A Simple but Effective GRC Tool** – Use AuditGlue to manage your documentation, conduct risk analyses, classify data, and prepare for audit in one integrated system.
|
||||
|
||||
**All Clauses and Controls explained** – Our Controls Library includes practical, plain-English examples for all 94 Annex A controls, specific to your type of organization.
|
||||
|
||||
**Expert Support on hand** – On-demand access to experienced ISO 27001 implementors when you need them.
|
||||
|
||||
**Preliminary Audits** – Plan sessions with certified auditors to validate your certification readiness.
|
||||
|
||||
**Our approach:**
|
||||
We want ISO 27001 to work for your organization. No cookie-cutter procedures or Theatre of Compliance. We help you identify what's already working in your organization, enhance it, document it properly, and integrate security into how you actually operate.
|
||||
|
||||
We teach you to make informed decisions based on your context, risks, and capabilities – because that's what ISO 27001 is actually about.
|
||||
|
||||
**You've got this. We'll show you how.**
|
||||
|
||||
ISO27DIY: Get Certified – Keep Growing
|
||||
29
marketing/content/Snippets for marketing iso27DIY.md
Normal file
29
marketing/content/Snippets for marketing iso27DIY.md
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
Guided ISO 27001 implementation
|
||||
|
||||
- guided implementation with a clear path to success
|
||||
- at your pace
|
||||
- Tailored to your organization
|
||||
|
||||
|
||||
- All necessary policies, planning etc tailored to your specific organization and implementation scope
|
||||
- expert support by experienced lead implementors
|
||||
- Full blown GRC tooling included!
|
||||
|
||||
|
||||
I’m aiming at small companies that need ISO 27001 because their B2B clients require it, and want to do as much as they can themselves.
|
||||
iso27DIY will lead them through the implementation step by step, filling the GRC tool along the way.
|
||||
The focus is helping them implement the ISMS _process_ and identifying the artefacts already present in the organization that can serve as proof, filling in the missing pieces with LLM.
|
||||
|
||||
|
||||
**My goal is threefold:**
|
||||
- Help you implement an ISMS that will actually benefit your organization,
|
||||
- let you acquire the ISO 27001 certification,
|
||||
- and use as much of the documentation, procedures, logs and other artifacts that are already part of your organization.
|
||||
|
||||
**We Work with what you've got**
|
||||
A lot of the necessary processes and controls required in ISO 27001 are probably already in place within your organization. But you may call them by another name and don’t realize it. iso27DIY will help you identify them and document them in such a way, that you fulfill the requirements without fundamentally changing what you are doing right already.
|
||||
|
||||
**Like Steve Jobs introduction of the iPhone**
|
||||
It’s a stack of templates AND a GRC program AND a consultant leading you through the process.
|
||||
|
||||
The online service will offer guided implementation for iso 27001. It will make it easier, cheaper, less confusing, less painful, more tailored to the client's business then other solutions or approaches. Real Humans will be available for those moments where digital just doesn't cut it.
|
||||
1
marketing/content/eBook-Audit
Submodule
1
marketing/content/eBook-Audit
Submodule
|
|
@ -0,0 +1 @@
|
|||
Subproject commit bdc238de983b78e7f33e23dab3c42dbfe8916e9e
|
||||
|
|
@ -0,0 +1,71 @@
|
|||
# In 9 stappen naar ISO 27001-certificering
|
||||
|
||||
De meeste organisaties beginnen bij de maatregelen. Dat is de verkeerde volgorde — zonder fundament zak je voor de audit, ongeacht hoeveel maatregelen je hebt geïmplementeerd. Dat fundament leg je met de risicomanagement processen. Deze roadmap loodst je in de juiste volgorde door de certificering.
|
||||
## Stap 1 – Stel je doelen
|
||||
|
||||
ISO 27001 gaat in de kern over het beheersen van risico's. Risico's zijn gebeurtenissen die het lastiger maken om je doelen te bereiken. Om te weten welke risico's je aan moet pakken, moet je eerst je doelen als organisatie bepalen. Ga je voor snelle groei of stabiliteit? Continue innovatie of efficiency? Reputatie of maximale winst?
|
||||
|
||||
Als je dat helder hebt kun je ook je prioriteiten voor het ISMS stellen, bijv.: de privacy van onze patienten staat op één, of: onze kernsystemen zijn altijd beschikbaar, of: bij ernstige incidenten zijn we binnen een dag weer operationeel.
|
||||
|
||||
## Stap 2 – Breng de context in kaart
|
||||
|
||||
Risico's ontstaan in de context, intern en extern van de organisatie. Daarom schrijft ISO 27001 voor dat je die in kaart brengt. Welke dreigingen zijn er? Aan welke wet- en regelgeving moet je voldoen? Welke ontwikkelingen zie je bij je klanten, bij toezichthouders, binnen je personeelsbestand, in de technologie? Maak een SWOT en een Stakeholder analyse.
|
||||
|
||||
Vertaal dit naar risico's en kansen en vertaal dit naar wat je nodig hebt m.b.t. de informatievoorziening. Deze contextanalyse is belangrijke input voor de risicoanalyse in stap 6.
|
||||
|
||||
Documenteer de stappen die je genomen hebt om de context in kaart te brengen, en wie er bij betrokken waren. De auditor gaat er naar vragen.
|
||||
|
||||
## Stap 3 – Bepaal de verantwoordelijkheden
|
||||
|
||||
Voor het ISMS is het essentieel duidelijk te beschrijven wie waarvoor verantwoordelijk is, en wie de besluiten neemt. ISO 27001 noemt 3 rollen expliciet:
|
||||
- **de directie** ('top management') is eindverantwoordelijk voor het beleid en de werking van het ISMS, en dus voor de informatiebeveiliging. De uitvoering kan gedelegeerd worden, de aansprakelijkheid niet.
|
||||
- **risico-eigenaren** moeten bepalen of de risico's voldoende omlaag zijn gebracht, of dat aanvullende maatregelen nodig zijn. In de praktijk zijn dit business managers: hun doelstellingen lopen gevaar als de informatie onvoldoende beveiligd is.
|
||||
- **asset eigenaren** zijn verantwoordelijk voor passende maatregelen om 'hun' assets te beschermen. Asset owners zijn meestal IT mensen, en de uitvoering is vooral in kleinere organisaties belegd bij leveranciers.
|
||||
|
||||
Voor de verschillende onderdelen van het ISMS moet je verder zelf bepalen wie de beslissingen neemt, wie adviseert, wie uitvoert en wie geinformeerd moet worden. Leg dit vast in een RASCI-matrix.
|
||||
|
||||
## Stap 4 – Start met documenteren
|
||||
|
||||
ISO 27001 wil dat activiteiten gestructureerd, controleerbaar en herhaalbaar zijn. Daarom moet je documenteren. Dat gaat je ook helpen om te groeien van een organisatie die van incident naar incident holt, naar een organisatie met lerend vermogen die zich voortdurend verbeterd. Je documenteert vooraf – zo gaan we het doen, en achteraf – zo hebben we het gedaan en dit waren de resultaten. Geef je documentatie een versienummer en/of datum, sla het gestructureerd op, en maak duidelijk wie de verschillende soorten documentatie opstelt, controleert en aftekent. Plan ook een periodieke revisie van de documenten, om te kijken of ze nog aansluiten bij de werkelijkheid.
|
||||
|
||||
## Stap 5 – Classificeer informatie
|
||||
|
||||
Niet alle informatie heeft dezelfde bescherming nodig. Sommige informatie is zeer vertrouwelijk, andere juist per definitie publiek. Inventariseer de soorten informatie binnen je organisatie, en bedenk in hoeverre beschikbaarheid, vertrouwelijkheid en integriteit voor die verschillende soorten belangrijk is. Geef dit aan met Hoog, Midden, of Laag (bijvoorbeeld – andere indelingen mogen ook).
|
||||
Dit hangt samen met hoeveel risico je als organisatie wil, of kan, dragen.
|
||||
|
||||
Beschrijf ook waar de informatie 'leeft': op welke servers of bij welke leveranciers staat het, in welke software zit het, en waar wordt het gebruikt. Dit is een indicatie voor waar maatregelen moeten worden genomen.
|
||||
|
||||
## Stap 6 – Analyseer de risico's
|
||||
|
||||
Met de context-analyse uit stap 2 kunnen we de risico's nu verder in kaart brengen. Dit kun je doen door te kijken naar 4 aspecten:
|
||||
1. dreiging – wat kan er misgaan?
|
||||
2. kwetsbaarheid – hoe zijn we daar gevoelig voor?
|
||||
3. impact – wat zijn de gevolgen?
|
||||
4. waarschijnlijkheid – hoe groot is de kans?
|
||||
|
||||
Door impact en waarschijnlijkheid te kwalificeren – bijv. met 1, 2 of 3 – kun je een risicoscore berekenen: R = I x W. Dat helpt je om prioriteiten te bepalen.
|
||||
|
||||
Ieder risico krijgt een risico-eigenaar. Hij/zij moet in stap 7 het risicobehandelplan goedkeuren, en mag na uitvoering bepalen of het risico voldoende omlaag is gebracht. Het is verstandig om vooraf vast te stellen welke risicoscore acceptabel is. Ook hier speelt mee hoeveel risico de organisatie kan of wil dragen.
|
||||
|
||||
## Stap 7 – Beschrijf de maatregelen en plan de implementatie
|
||||
|
||||
Nu komen we bij de gevreesde 93 maatregelen uit Bijlage A. Het goede nieuws is dat je waarschijnlijk een flink aantal van de maatregelen al toepast, intern of via een leverancier. Je kunt beginnen deze maatregelen te inventariseren, en zo te documenteren dat ze passen in het framework van ISO 27001. Belangrijk is dat je de maatregelen relateert aan specifieke risico's (uit stap 6), en het toepassingsgebied van een maatregel koppelt aan de informatieclassificatie (stap 5).
|
||||
|
||||
Voor de maatregelen die overblijven zul je een zinvolle plek moeten vinden om ze toe te passen, of moeten beargumenteren waarom juist jij ze niet nodig hebt. Dit leg je vast in je 'Statement of Applicability'. Je hoeft niet alle toepasselijke maatregelen volledig geimplementeerd te hebben voor certificering, mits je een duidelijk onderbouwd plan hebt voor de implementatie (zie stap 8), in overeenstemming met je prioriteitenstelling uit stap 6 (de Risicoanalyse).
|
||||
|
||||
## Stap 8 – Implementeer de maatregelen
|
||||
|
||||
Stel per maatregel beleid op dat beschrijft hoe de maatregel wordt uitgevoerd. Wie is verantwoordelijk? Hoe vaak wordt de maatregel uitgevoerd of gecontroleerd? Wat zijn de criteria voor succes? Documenteer ook de uitvoering zelf — een auditor wil niet alleen het beleid zien, maar ook het bewijs dat het beleid wordt nageleefd (zie ook stap 4).
|
||||
|
||||
In de praktijk worden systemen en diensten vaak door derden geleverd, zeker in het MKB, en tegenwoordig bijna volledig 'in de cloud'. Aan deze leveranciers moeten eisen gesteld worden qua prestaties en beveiliging, en vastgelegd worden in overeenkomsten. Hierbij geldt de vuistregel: de eisen die je aan je eigen organisatie stelt, moet je ook aan je leveranciers stellen. Deze afspraken moet je meetbaar maken, zodat je de naleving kunt controleren. Ook dit leg je vast als beleid.
|
||||
|
||||
## Stap 9 – Borg het ISMS in de organisatie
|
||||
|
||||
Om te zorgen voor voortdurende verbetering – een eis van ISO 27001 – zul je een feedback loop moeten organiseren. Dat wil zeggen dat je de effectiviteit van de ISMS processen en maatregelen meet, en periodiek kijkt waar verbeteringen nodig of wenselijk zijn.
|
||||
|
||||
Er zijn in ieder geval twee concrete momenten waarop een evaluatie plaats moet vinden, volgens ISO 27001. Periodiek, ten minste jaarlijks, is er een zgn. directiebeoordeling ('management review'), waarin het topmanagement de werking van het ISMS beoordeelt en aanwijzingen geeft voor verbetering. Daarnaast moeten op geplande momenten interne audits uitgevoerd worden.
|
||||
|
||||
Maar wil je dat het ISMS ècht wat voor je organisatie doet – namelijk een solide organisatie van de informatiebeveiliging – dan moet je het integreren met de management cyclus. Dat doe je door de risico-eigenaren (business managers, zie stap 3) daadwerkelijk verantwoordelijk te maken voor het risiconiveau binnen hun management scope.
|
||||
## Tot Slot
|
||||
|
||||
Deze road map gaat met zevenmijlslaarzen door de implementatie van ISO 27001 heen – dat is de functie ervan. Het is geen 'rocket science', en ook geen zinloze formulierenwinkel. ISO 27001 vergt tijd en aandacht, maar je krijgt er veiligheid, beheersbaarheid, schaalbaarheid en adaptabiliteit voor terug. Meer ondersteuning nodig? Kijk op [iso27diy.com](https://www.iso27diy.com).
|
||||
12
marketing/content/website/blog/9-steps-alternatieve-titel.md
Normal file
12
marketing/content/website/blog/9-steps-alternatieve-titel.md
Normal file
|
|
@ -0,0 +1,12 @@
|
|||
"In 9 stappen naar ISO 27001-certificering" is functioneel maar saai. "In X stappen naar Y" is een van de meest gebruikte blogpost-formules op internet. Hij belooft structuur, maar zegt niets over wat de lezer er anders aan vindt dan de duizend andere lijstjes over ISO 27001.
|
||||
|
||||
Je blogpost heeft wél een scherpe invalshoek: **de volgorde is wat de meeste mensen fout doen**. Dat staat nu alleen in de eerste zin van de post, niet in de titel.
|
||||
|
||||
Alternatieven die dichter bij je werkelijke argument zitten:
|
||||
|
||||
- **ISO 27001: begin niet bij de maatregelen** — direct, tegendraads, triggert herkenning
|
||||
- **De verkeerde volgorde is waarom ISO 27001-trajecten mislukken** — iets langer maar concreet
|
||||
- **ISO 27001 in de juiste volgorde: 9 stappen** — zwakker dan de eerste twee, maar al beter dan het origineel
|
||||
- **Waarom je ISO 27001 niet begint bij Bijlage A** — werkt goed voor mensen die al weten wat Bijlage A is (jouw doelgroep waarschijnlijk wel)
|
||||
|
||||
De eerste of de laatste zou ik serieus overwegen. Ze sluiten ook beter aan op de LinkedIn-posts die ik schreef, waar die haak het sterkste element is.
|
||||
|
|
@ -0,0 +1,76 @@
|
|||
# ISO 27001 Certification in 9 Steps
|
||||
|
||||
Most organisations start with the controls — which is the wrong way. Without a solid foundation, you will fail the audit, no matter how many controls you have implemented. You build that foundation through your risk management processes. Controls come after. This roadmap takes you through the certification in the right order.
|
||||
|
||||
## Step 1 – Define your objectives
|
||||
|
||||
ISO 27001 is fundamentally about managing risk. Risks are events that make it harder to achieve your objectives. To know which risks to address, you first need to know what your organisation is trying to achieve. Are you pursuing rapid growth or stability? Continuous innovation or operational efficiency? Reputation or maximum profit?
|
||||
|
||||
Once that is clear, you can set your priorities for the ISMS — for example: the privacy of our patients comes first; or: our core systems must always be available; or: in the event of a serious incident, we are back up and running within a day.
|
||||
|
||||
## Step 2 – Map the context
|
||||
|
||||
Risks arise from context — both internal and external. That is why ISO 27001 requires you to map it. What threats exist? Which laws and regulations apply? What developments do you see among your customers, regulators, your workforce, or in technology? Conduct a SWOT analysis and a stakeholder analysis.
|
||||
|
||||
Translate this into risks and opportunities, and then into what you need in terms of information management. This context analysis is critical input for the risk assessment in step 6.
|
||||
|
||||
Document the steps you took to map the context, and who was involved. The auditor will ask.
|
||||
|
||||
## Step 3 – Assign responsibilities
|
||||
|
||||
A functioning ISMS requires clarity about who is responsible for what, and who makes which decisions. ISO 27001 explicitly names three roles:
|
||||
|
||||
- **Top management** is ultimately responsible for the policy and operation of the ISMS, and therefore for information security. Execution can be delegated — liability cannot.
|
||||
- **Risk owners** determine whether risks have been reduced sufficiently, or whether additional controls are needed. In practice, these are business managers: their objectives are at stake when information is inadequately protected.
|
||||
- **Asset owners** are responsible for appropriate controls to protect their assets. Asset ownership often sits with the IT function, and in smaller organisations execution is often handled by third-party suppliers.
|
||||
|
||||
For the various components of the ISMS, you will need to determine who decides, who advises, who executes, and who is kept informed. Capture this in a RASCI matrix.
|
||||
|
||||
## Step 4 – Start documenting
|
||||
|
||||
ISO 27001 requires activities to be structured, verifiable, and repeatable. That means documenting. It will also help you grow from an organisation that stumbles from incident to incident, to one with the capacity to learn and continuously improve. You document upfront — this is how we will do it — and afterwards — this is what we did, and these were the results. Version and date your documentation, store it in a structured way, and make clear who drafts, reviews, and signs off each type of document. Schedule periodic reviews to check whether documents still reflect reality.
|
||||
|
||||
## Step 5 – Classify your information
|
||||
|
||||
Not all information needs the same level of protection. Some information is highly confidential; other information is public by definition. Inventory the types of information within your organisation and consider how important availability, confidentiality, and integrity are for each type. Indicate this with High, Medium, or Low — or a classification scheme of your own choosing.
|
||||
|
||||
This is connected to how much risk your organisation is willing, or able, to carry.
|
||||
|
||||
Also describe where the information lives: which servers or suppliers hold it, which software contains it, and where it is used. This indicates where controls need to be applied.
|
||||
|
||||
## Step 6 – Assess the risks
|
||||
|
||||
With the context analysis from step 2, you can now map the risks in detail. Look at four dimensions:
|
||||
|
||||
1. **Threat** — what could go wrong?
|
||||
2. **Vulnerability** — how exposed are we?
|
||||
3. **Impact** — what are the consequences?
|
||||
4. **Probability** — what is the likelihood?
|
||||
|
||||
By scoring probability and impact — for example, 1, 2, or 3 — you can calculate a risk score: R = P x I. This helps you set priorities.
|
||||
|
||||
Each risk gets a risk owner. They will need to approve the risk treatment plan in step 7, and after implementation, they determine whether the risk has been reduced sufficiently. It is advisable to agree in advance what risk score is acceptable. Here too, the organisation's risk appetite is a factor.
|
||||
|
||||
## Step 7 – Define controls and plan implementation
|
||||
|
||||
Now we arrive at the infamous 93 controls of Annex A. The good news is that you are probably already applying a significant number of them — internally or through a supplier. Start by inventorying those controls and documenting them in a way that fits the ISO 27001 framework. What matters is that you link each control to specific risks from step 6, and tie its scope to the information classification from step 5.
|
||||
|
||||
For the remaining controls, you will need to find a meaningful place to apply them — or argue why they do not apply to your organisation. This is captured in your Statement of Applicability. You do not need to have all applicable controls fully implemented before certification, provided you have a clearly substantiated implementation plan (see step 8), aligned with your priorities from the risk assessment in step 6.
|
||||
|
||||
## Step 8 – Implement the controls
|
||||
|
||||
For each control, draft a policy that describes how it is carried out. Who is responsible? How often is the control executed or reviewed? What are the success criteria? Document the execution itself as well — an auditor wants to see not only the policy, but evidence that the policy is being followed (see also step 4).
|
||||
|
||||
In practice, systems and services are frequently provided by third parties — especially in SMEs, and today almost entirely from the cloud. You need to set requirements for these suppliers in terms of performance and security, and capture them in contracts. The rule of thumb: the standards you hold yourself to, you must also hold your suppliers to. Make these agreements measurable, so you can verify compliance. Document this as policy.
|
||||
|
||||
## Step 9 – Embed the ISMS in the organisation
|
||||
|
||||
To ensure continual improvement — a requirement of ISO 27001 — you need to build a feedback loop. That means measuring the effectiveness of your ISMS processes and controls, and periodically reviewing where improvement is needed or desirable.
|
||||
|
||||
ISO 27001 prescribes at least two formal evaluation moments. Top management must conduct a management review at least once a year, assessing the performance of the ISMS and providing direction for improvement. In addition, internal audits must be carried out at planned intervals.
|
||||
|
||||
If you want the ISMS to really deliver — a solid, well-organised approach to information security — you need to integrate it with your management cycle. Do that by making the risk owners (business managers, see step 3) accountable for the risk level within their area of responsibility.
|
||||
|
||||
## In Closing
|
||||
|
||||
This roadmap moves through the ISO 27001 implementation at pace — that is its function. It is not rocket science, and it is not a pointless paperwork exercise. ISO 27001 requires time and attention, but in return you get security, manageability, scalability, and adaptability. Need more support? Visit [iso27diy.com](https://www.iso27diy.com).
|
||||
73
marketing/content/website/blog/promoting-9-steps.md
Normal file
73
marketing/content/website/blog/promoting-9-steps.md
Normal file
|
|
@ -0,0 +1,73 @@
|
|||
# Promotie: "In 9 stappen naar ISO 27001-certificering"
|
||||
|
||||
## Blogpost
|
||||
**Bestand:** `iso27DIY-mkII/Website/Content/blog/9-stappen-naar-ISO-27001-certificering.md`
|
||||
**Kernargument:** De meeste organisaties beginnen bij de maatregelen — dat is de verkeerde volgorde. Het fundament is risicomanagement, en dat begint bij organisatiedoelen.
|
||||
|
||||
---
|
||||
|
||||
## Titeldiscussie
|
||||
|
||||
De originele titel ("In 9 stappen naar ISO 27001-certificering") is te generiek. De echte haak zit in de invalshoek: de volgorde is wat de meeste mensen fout doen.
|
||||
|
||||
**Betere alternatieven:**
|
||||
- **ISO 27001: begin niet bij de maatregelen** ← sterkste optie
|
||||
- **Waarom je ISO 27001 niet begint bij Bijlage A** ← goed voor de doelgroep
|
||||
- De verkeerde volgorde is waarom ISO 27001-trajecten mislukken
|
||||
- ISO 27001 in de juiste volgorde: 9 stappen
|
||||
|
||||
---
|
||||
|
||||
## Promotiemateriaal per kanaal
|
||||
|
||||
### LinkedIn — lang
|
||||
> De meeste organisaties beginnen met de maatregelen. Verkeerde volgorde.
|
||||
>
|
||||
> Zonder fundament zak je voor de audit — ongeacht hoeveel je hebt geïmplementeerd.
|
||||
>
|
||||
> Het fundament is risicomanagement. En risicomanagement begint bij je doelen als organisatie. Wat wil je bereiken? Pas dan weet je welke risico's er toe doen.
|
||||
>
|
||||
> Ik heb de 9 stappen naar ISO 27001-certificering uitgeschreven — in de juiste volgorde, inclusief de logica erachter.
|
||||
>
|
||||
> Geen rocket science. Wel discipline.
|
||||
>
|
||||
> 👉 [link naar blogpost]
|
||||
|
||||
*Gebruik: persoonlijk profiel, thought leadership toon.*
|
||||
|
||||
---
|
||||
|
||||
### LinkedIn — kort
|
||||
> ISO 27001 beginnen bij de maatregelen? Klassieke fout.
|
||||
>
|
||||
> De juiste volgorde: doelen → context → risico's → maatregelen.
|
||||
>
|
||||
> In 9 stappen uitgelegd — inclusief wat de auditor wil zien.
|
||||
>
|
||||
> 👉 [link]
|
||||
|
||||
*Gebruik: company page of als kortere variant.*
|
||||
|
||||
---
|
||||
|
||||
### X / Twitter
|
||||
> Meeste bedrijven beginnen ISO 27001 bij de maatregelen. Auditor is niet blij.
|
||||
>
|
||||
> De juiste volgorde begint bij je doelen als organisatie.
|
||||
>
|
||||
> 9 stappen, uitgelegd: [link]
|
||||
|
||||
---
|
||||
|
||||
### Nieuwsbrief (teaser)
|
||||
> ISO 27001-certificering mislukt zelden door slechte maatregelen — het mislukt door de verkeerde volgorde. Wie begint bij Bijlage A, bouwt op drijfzand. Ik heb de 9 stappen uitgeschreven zoals ze logisch op elkaar volgen, met uitleg waarom elke stap doet wat hij doet. Lees het hier: [link]
|
||||
|
||||
---
|
||||
|
||||
### WhatsApp / Slack
|
||||
> Nieuwe blogpost: In 9 stappen naar ISO 27001-certificering — in de juiste volgorde. Niet beginnen bij de maatregelen dus. [link]
|
||||
|
||||
---
|
||||
|
||||
## UTM-parameters (ter herinnering)
|
||||
Gebruik per kanaal een eigen `utm_source` + `utm_medium`, zodat Umami de traffic per kanaal onderscheidt. Campagnenaam bijv.: `iso27001-basics-q2-2026`.
|
||||
38
marketing/content/website/blog/tsw-manifesto.md
Normal file
38
marketing/content/website/blog/tsw-manifesto.md
Normal file
|
|
@ -0,0 +1,38 @@
|
|||
---
|
||||
title: "The Manifesto for Information Security Management"
|
||||
description: "Every organization can build a mature security management system, creating compliance without complexity. Security management that adds actual business value by facilitating agility instead of introducing rigidity. Without hefty consulting bills."
|
||||
date: 2026-03-23
|
||||
categories: ["Company"]
|
||||
tags: ["manifesto", "philosophy"]
|
||||
draft: false
|
||||
---
|
||||
|
||||
Through working with our clients we have come to value:
|
||||
|
||||
* Business over security
|
||||
* Purpose over policy
|
||||
* Iteration over perfection
|
||||
* Risk-based decisions over checkbox compliance
|
||||
|
||||
While there is value in the items on the right, the items on the left are what makes security last.
|
||||
|
||||
---
|
||||
|
||||
## Our 10 Principles for implementing an effective ISMS
|
||||
|
||||
*We follow these principles:*
|
||||
|
||||
1. Our highest priority is to enable the business to achieve its goals with effective information security.
|
||||
2. Adaptability is the foundation of good security.
|
||||
3. Accountability for security rests with business management.
|
||||
4. Every employee, at every level, carries an active responsibility for security within their own work scope. Leadership creates the conditions for this to happen.
|
||||
5. Security professionals and business stakeholders meet regularly, face to face, to discuss risks and measures in the context of real work.
|
||||
6. An exception properly handled is better than a rule blindly followed. Deviations are mostly a sign of bad policies, not of bad people.
|
||||
7. Abstract risks breed diffuse responsibilities. A risk that belongs to everyone is a risk that belongs to no one.
|
||||
8. Risk arises where work is done. Those doing the work are best placed to identify it.
|
||||
9. Maturity requires reflection. Regularly examine what is working, what is not, and why. Adjust accordingly.
|
||||
10. Do the right thing!
|
||||
|
||||
By following these principles, any organisation can build information security management that enables the business, adapts to change, and is carried by everyone in it.
|
||||
|
||||
© 2026 Thinking Security Works
|
||||
83
marketing/content/website/homepage.md
Normal file
83
marketing/content/website/homepage.md
Normal file
|
|
@ -0,0 +1,83 @@
|
|||
# HOMEPAGE – Get ready for ISO 27001 certification.
|
||||
**No consulting required.**
|
||||
|
||||
[Start Your Free Trial](#) — *No credit card required*
|
||||
|
||||
---
|
||||
|
||||
## All you need to manage ISO 27001 compliance.
|
||||
|
||||
### Build the ISMS That Fits Your Business
|
||||
Produce organization-specific, auditable evidence for each ISO 27001 requirement in 50+ guided micro-sessions.
|
||||
|
||||
### Map Your Security Controls
|
||||
Connect your existing security practices to the right Annex A controls. Find the gaps and close them with the help of our comprehensive Knowledge Base.
|
||||
|
||||
### Manage Your Documentation
|
||||
Keep your documentation audit-ready with our AuditGlue GRC tool.
|
||||
|
||||
AuditGlue supports AI-powered policy generation, version control, and task management.
|
||||
|
||||
### Human Support Available
|
||||
Get answers to your questions from our ISO 27001 Experts via email or chat. Schedule a video call for detailed advice or arrange a pre-certification audit with our PECB Certified Lead Auditors.
|
||||
|
||||
---
|
||||
|
||||
## ISO27DIY is the right choice if:
|
||||
|
||||
### You're a Small Team Chasing Enterprise Deals
|
||||
Enterprise clients demand ISO 27001 certification. ISO27DIY helps you meet that requirement, without the enterprise budget.
|
||||
|
||||
### You Want Guidance, Not Consultants
|
||||
ISO27DIY supports you in doing as much as possible yourself, with a complete toolkit built by experienced ISO 27001 auditors and implementers.
|
||||
|
||||
### You Want Compliance to Actually Mean Something
|
||||
ISO27DIY helps you integrate information security with the way you work, creating a business that's genuinely more resilient — with the certificate to prove it.
|
||||
|
||||
---
|
||||
|
||||
## Simple, transparent pricing.
|
||||
**No consultants. No surprises.**
|
||||
|
||||
### Implementation — €39/month
|
||||
*billed annually · €49 billed monthly*
|
||||
|
||||
Everything you need to get certified.
|
||||
|
||||
- ✅ Guided Implementation System
|
||||
- ✅ Knowledge Base — all clauses & controls
|
||||
- ✅ AuditGlue GRC tool
|
||||
- ➕ Additional logins at €10.99/month
|
||||
|
||||
[Start free trial](https://iso.nekoluka.nl/login)
|
||||
|
||||
---
|
||||
|
||||
### Implementation + Support — €99/month ⭐ Most Popular
|
||||
*billed annually · €119 billed monthly*
|
||||
|
||||
All of the above, plus expert support.
|
||||
|
||||
- ✅ Everything in Implementation
|
||||
- ✅ Unlimited* email & chat support
|
||||
- ✅ ISO 27001 experts, next business day
|
||||
|
||||
[Start free trial](https://iso.nekoluka.nl/login)
|
||||
|
||||
---
|
||||
|
||||
## Add-ons
|
||||
|
||||
### Pre-certification audit — €299 per session
|
||||
Know where you stand before the real thing.
|
||||
|
||||
PECB Certified Lead Auditor, by video call. 3-hour sessions — a full audit typically takes 4 sessions.
|
||||
|
||||
[Book a pre-audit →](#)
|
||||
|
||||
### Expert video call — €49 per call
|
||||
Stuck? Get 30 minutes with a certified auditor.
|
||||
|
||||
One-on-one with a PECB Certified Lead Auditor. No fluff, just answers.
|
||||
|
||||
[Book a call →](#)
|
||||
Loading…
Add table
Add a link
Reference in a new issue