diff --git a/.github/workflows/deploy.yml b/.github/workflows/deploy.yml
index 08d1d8c..6f7bc5d 100644
--- a/.github/workflows/deploy.yml
+++ b/.github/workflows/deploy.yml
@@ -5,7 +5,7 @@ name: MyST GitHub Pages Deploy
 on:
   push:
     # Runs on pushes targeting the default branch
-    branches: [master]
+    branches: [main]
 env:
   # `BASE_URL` determines, relative to the root of the domain, the URL that your site is served from.
   # E.g., if your site lives at `https://mydomain.org/myproject`, set `BASE_URL=/myproject`.
@@ -35,7 +35,7 @@ jobs:
         uses: actions/configure-pages@v3
       - uses: actions/setup-node@v4
         with:
-          node-version: 18.x
+          node-version: 24.x
       - name: Install MyST
         run: npm install -g mystmd
       - name: Build HTML Assets
diff --git a/README.md b/README.md
index 5b0a16b..88b8554 100644
--- a/README.md
+++ b/README.md
@@ -1,22 +1,131 @@
 # README
 
-Security by design is a proven method to develop products that are less vulnerable for cyber security threats.
 
-Security by design is not a product. Nor a simple straight through process. Security by design can be viewed as a core philosophy to do the right things from a cyber security perspective in every action performed when developing and producing a new product.
+## 🛡️ Mastering Security By Design
 
-## HELP
+[![License: CC BY-SA 4.0](https://img.shields.io/badge/License-CC%20BY--SA%204.0-blue.svg)](https://creativecommons.org/licenses/by-sa/4.0/)
+[![PRs Welcome](https://img.shields.io/badge/PRs-welcome-brightgreen.svg)](http://makeapullrequest.com)
+[![Jupyter Book](https://img.shields.io/badge/Built%20with-Jupyter%20Book-blue)](https://jupyterbook.org/)
+[![PythonCodeAudit Badge](https://img.shields.io/badge/Python%20Code%20Audit-Security%20Verified-FF0000?style=flat-square)](https://github.com/nocomplexity/codeaudit)
 
-The best way to help is share this Open PlayBook! So share the link to with your colleagues.
+> **Security by Design is not a product. It is a proven philosophy to build products less vulnerable to cyber threats.**
 
-This is a living document and will continue to be updated with more helpful information and examples as they become available.
+> [!TIP]
+> **Mastering Security by Design requires is a shift in thinking.**  
+> Move beyond reactive, bolt-on measures. Weave security into every action — from the first whiteboard sketch to decommissioning.
 
-The latest version of this book is always published on the URL:
+---
 
-[Security by Design](https://nocomplexity.com/documents/securitybydesign/intro.html):
+## What is This?
 
+Security by Design is a **structured framework**, not a single activity or a straight-through process. It organizes chaotic security efforts into a **coherent, repeatable system** — just like a building requires foundations, wiring, and plumbing working together.
 
-This book is created with [Jupyterbook](https://jupyterbook.org/).
+> [!IMPORTANT]
+> A framework is **not a checklist**. It is a system of dependencies.  
+> Each topic below is useless in isolation. Master them together to drive the engine of true Security by Design.
 
-Create a pull request if you see errors, or have suggestions and improvements, 
+![Security by Design Framework](https://nocomplexity.github.io/securitybydesign/build/sbd_framework-3cd99d67f922c9a202842530536f7610.png)
 
-This book is open source. Issues and pull requests are welcome!
\ No newline at end of file
+---
+
+## Why a Framework View?
+
+| Fallacy | Reality |
+|---------|---------|
+| "Let's just do threat modeling" | Without risk assessment, you get an unprioritized list of every possible attack. |
+| "Let's just buy a monitoring tool" | Without security principles and policies, tools create noise, not security. |
+| "AI will solve this" | AI lacks context. Human thinking is non-negotiable. |
+
+> [!WARNING]
+> **Avoid the "Silver Bullet" Fallacy.**  
+> Chasing one solution while ignoring other topics guarantees failure.
+
+---
+
+## Essential Topics
+
+Mastering each topic below is **non-negotiable** for building secure, resilient, and trustworthy systems.
+
+| Topic | Why It Matters |
+|-------|----------------|
+| **[What is Security by Design](basics.md)** | Define the core philosophy: shift left, embed controls, enable not block. |
+| **[Prevention](prevention/prevention_intro.md)** | Architect systems that resist attacks by default — reduce attack surface, eliminate vulnerability classes. |
+| **[Threat Modeling](threatmodeling/threatmodeling_intro.md)** | Identify and prioritize adversaries and attack paths early — turn security from guesswork into engineering science. |
+| **[Security Monitoring](monitoring/monitoring_intro.md)** | Build observable systems that signal distress in real time — detect anomalies, validate controls. |
+| **[Security Policies](policies/policies_intro.md)** | Create clear, enforceable rules on access, encryption, and risk — design systems that enforce policy technically. |
+| **[Risk Assessment](riskassesment/ra_intro.md)** | Make informed trade-offs — prioritize controls, speak the language of business leaders. |
+| **[Security Management](securitymanagement/securitymanagement_intro.md)** | Run security as a management discipline — governance, resource allocation, boardroom to build server. |
+| **[Security Principles](principles/principles_intro.md)** | Master timeless laws: least privilege, defence in depth, fail secure — your mental checklist when complexity overwhelms. |
+| **[Security Architecture](securityarchitecture/architecture_intro.md)** | Apply patterns, reference models, and reviews — design secure by composition, not accident. |
+| **[Secure SDLC](ssdlc/ssdlc_intro.md)** | Integrate threat modeling, static analysis, secure coding, testing — make security a continuous partner, not a gate. |
+| **[Security Culture](culture/culture_intro.md)** | Foster psychological safety to report incidents — reward secure behavior, move from blame to learning. |
+| **[Open Source Security](foss/foss_intro.md)** | Vet, monitor, and maintain dependencies — turn the ecosystem from liability into asset. |
+| **[Security Training](training/training_intro.md)** | Ensure every engineer and owner has baseline knowledge — create internal champions. |
+
+> [!NOTE]
+> Do not view these as isolated chapters. See them as **interlocking gears**. When turned together, they drive true Security by Design.
+
+---
+
+## How to Help
+
+> [!HELP]
+> **The best way to help is to share this Open PlayBook!**  
+> Share the link with your colleagues:  
+> 🔗 [Mastering Security by Design PlayBook](http://securitybydesign.nocomplexity.com)
+
+- ✅ This is a **living document** — continuously updated with more examples and insights.
+- ✅ **Latest version** always at the URL above.
+- ✅ Built with [JupyterBook](https://jupyterbook.org/).
+- ✅ **Open source** — issues and pull requests are **welcome**!
+
+You don't have to be a security expert to contribute, every contribution is welcome!
+> [!TIP]
+> **See an error or have a suggestion?**  
+> If you wish to make comments regarding this document, please raise them as [GitHub issues](https://github.com/nocomplexity/securitybydesign). Send comments by email if you are unable to raise issues on GitHub do not to use Github on principle. All comments are welcome!
+
+
+---
+
+## About This Course
+
+To truly master **Security by Design**, you must move beyond the past. This course gives you the **framework, topics, and human-centered approach** to build systems that are secure, resilient, and trustworthy by their very nature.
+
+
+---
+
+**Ready to master Security by Design?**  
+👉 [Start Reading the Full Book](https://nocomplexity.github.io/securitybydesign/)
+
+
+## License
+
+This publication is:
+
+(c) 2021-2026 [BM-Support.org](https://www.bm-support.org/) - Maikel & Asim and all contributors
+
+This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Third-party product names may be the trademarks of their respective owners.
+
+See http://creativecommons.org/licenses/by-sa/4.0/ for the full license text. 
+
+
+
+### Using and reusing this document
+
+This Security by Design publication  is created to be used and improved by you! 
+
+If you do use or reuse content of this Playbook I would appreciate attribution.
+
+The simplest way to give attribution to this work is by including the following line in your derived publication:
+
+> Attribution Suggestion
+```
+NoComplexity.com, [Security by Design ](https://nocomplexity.com/), licensed CC BY-SA 4.0. 
+
+```
+
+
+
+This publication is real open content. We believe open access is mandatory for simplifying and improving cyber security.
+
+We believe in openness to [simplify cyber security](https://nocomplexity.com/simplify-security/).
diff --git a/_toc.yml b/_toc.yml
deleted file mode 100644
index 9dee9a9..0000000
--- a/_toc.yml
+++ /dev/null
@@ -1,35 +0,0 @@
-# Table of contents
-# Learn more at https://jupyterbook.org/customize/toc.html
-# For JB1 version!
-
-
-format: jb-book
-root: intro
-
-parts:
-  - caption: Aspects
-    chapters:
-    - file: prevention
-    - file: securitymonitoring
-    - file: securitypolicies
-    - file: protection
-    - file: riskassessment
-    - file: securitymanagement
-    - file: securityarchitecture
-    - file: securityprinciples
-    - file: sdlc
-    - file: securityculture
-    - file: opensecurity
-    - file: training
-  - caption: About
-    chapters:
-    - file: help
-    - file: contribute
-    - file: attribution
-    - file: sponsors
-    - file: open
-    - file: connect
-    - file: license
-    - file: about
-    
-    
\ No newline at end of file
diff --git a/aboutnocx.md b/aboutnocx.md
index 8a6505e..f670353 100644
--- a/aboutnocx.md
+++ b/aboutnocx.md
@@ -9,6 +9,8 @@ With experience across a range of architecture roles—including IT Architect, S
 
 Currently, I lead initiatives at [NO|Complexity.com](https://nocomplexity.com/), an innovative IT company focused on straightforward solutions based in the Netherlands.
 
++++{"no-pdf": true}
+
 ## Other NO|Complexity Publications
 
 ### Cyber Security 
@@ -127,4 +129,8 @@ This is an eBook with proven scientific tools and frameworks to help you effecti
 
 
 ::::
-% End of Cards grid
\ No newline at end of file
+% End of Cards grid
+
+
++++ 
+% End of part that will not be shown in PDF - automatic transform will not work - status May 2026 -
\ No newline at end of file
diff --git a/contribute.md b/contribute.md
index 00531df..06e16d8 100644
--- a/contribute.md
+++ b/contribute.md
@@ -1,4 +1,8 @@
-# Contribute
+---
+title: Contribute
+short_title: Contribute
+---
+
 
 Great that you’re here and want to contribute! 
 
@@ -17,7 +21,6 @@ The **simplest** way to make a comment for a specific page is to use the Github
 
 
 
-
 ## Pay what you can 
 
 **Cybersecurity education shouldn't be a luxury.**
diff --git a/culture/culture_intro.md b/culture/culture_intro.md
index 6730135..16f65fb 100644
--- a/culture/culture_intro.md
+++ b/culture/culture_intro.md
@@ -31,9 +31,24 @@ By the end of this section, you will be able to:
 - Evaluate the effectiveness of awareness activities using behavioural metrics rather than completion rates
 - Explain how security culture aligns with and supports broader Security by Design principles across enterprise architecture and management systems
 
++++{"no-pdf": true}
 
 ## Sections
 
+
 :::{toc}
 :context: children
-:::
\ No newline at end of file
+:::
+
++++
+
+
+:::{raw:typst}
+*Sections*
+
+- What is a Security Culture
+- How to create A Security By Design Culture
+- Implement Security Awareness
+- Making Security awareness work
+
+:::
diff --git a/foss/foss_intro.md b/foss/foss_intro.md
index 3e2f4b2..55464ae 100644
--- a/foss/foss_intro.md
+++ b/foss/foss_intro.md
@@ -29,9 +29,26 @@ By the end of this section, you will be able to:
 - Apply a disciplined checklist to assess the security, quality, and sustainability of open source components
 - Describe practical strategies for building verifiable trust in software dependencies without assuming that "open" automatically means "secure"
 
+
+
++++{"no-pdf": true}
+
 ## Sections
 
 
 :::{toc}
 :context: children
 :::
+
++++
+
+
+:::{raw:typst}
+*Sections*
+
+- FOSS Security
+- How to trust software?
+- Checklist Guide for Evaluating Open Source Software
+- Checklist for Python Security Applications
+
+:::
diff --git a/foss/pythonsecsoftware.md b/foss/pythonsecsoftware.md
index 2b3618f..cddb1f3 100644
--- a/foss/pythonsecsoftware.md
+++ b/foss/pythonsecsoftware.md
@@ -43,7 +43,7 @@ A fuzzer SHOULD be incorporated into the testing workflow where appropriate to i
 
 
 A formal architecture or design document MUST exist, outlining key principles and documenting the design decisions that guided the implementation. It is RECOMMENDED that a "Security by Design" approach is followed to ensure security principles are integrated into every stage of the SDLC cycle.
-A common practice is to maintain an [ARCHITECTURE.md](architecture) file within the repository.
+A common practice is to maintain an `ARCHITECTURE.md` file within the repository.
 This document SHOULD be released under a Creative Commons licence (or equivalent) and MUST be available without limitation to allow for public review and improvement.
 
 +++
diff --git a/images/SbD_pdf_cover2026.png b/images/SbD_pdf_cover2026.png
new file mode 100644
index 0000000..24cd740
Binary files /dev/null and b/images/SbD_pdf_cover2026.png differ
diff --git a/images/sbd_bookcover.png b/images/sbd_bookcover.png
new file mode 100644
index 0000000..eb99602
Binary files /dev/null and b/images/sbd_bookcover.png differ
diff --git a/intro.md b/intro.md
index 472cf5e..27a5ec1 100644
--- a/intro.md
+++ b/intro.md
@@ -1,5 +1,12 @@
 # Welcome to Mastering Security By Design
 
+:::{image} /images/sbd_bookcover.png
+:alt: Book Cover Mastering Security By Design
+:width: 300px
+:height: 400px
+:align: center
+:::
+
 
 :::{tip} Welcome! 
 This book will give you a deep understanding of what Security by Design is and how to apply this in practice.
diff --git a/introduction/introduction_intro.md b/introduction/introduction_intro.md
index b338ba7..4b14a71 100644
--- a/introduction/introduction_intro.md
+++ b/introduction/introduction_intro.md
@@ -16,9 +16,25 @@ By the end of this section, you should be able to:
 - **Describe the framework of Security By Design topics** – Identify the key interdependent topics (such as threat modeling, risk assessment, security architecture, and security culture) and explain why no single topic is sufficient on its own.
 - **Distinguish between explicit and tacit knowledge in security** – Recognise the difference between codified rules (explicit) and experience-based judgement (tacit), and explain why both are necessary to master Security By Design.
 
++++{"no-pdf": true}
+
 ## Sections
 
 
 :::{toc}
 :context: children
-:::
\ No newline at end of file
+:::
+
++++
+
+
+
+:::{raw:typst}
+*Sections*
+
+- What is Security by Design
+- Security By Design Topics
+- Explicit Knowledge and Tacit Knowledge
+:::
+
+
diff --git a/introduction/topics.md b/introduction/topics.md
index 36ede5a..fddb25b 100644
--- a/introduction/topics.md
+++ b/introduction/topics.md
@@ -50,40 +50,40 @@ Below is an introduction to why each topic is critical to your journey on Master
 - **[What is Security by Design](basics.md)**  
   Before you can practice it, you must define it. This topic establishes the core philosophy: shifting security left, embedding controls from the outset, and treating security as an enabler, not a blocker. Understanding the ‘what’ and ‘why’ sets the foundation for every decision that follows.
 
-- [**Prevention**](prevention/prevention_intro.md)  
+- [**Prevention**](../prevention/prevention_intro.md)  
   Prevention is the ultimate expression of proactive security. While detection and response are necessary safeties, relying on them is a sign of incomplete design. This topic teaches you how to architect systems that resist attacks by default—reducing the attack surface, enforcing least privilege, and eliminating entire classes of vulnerabilities before they can be exploited.
 
-- [**Threat Modeling**](threatmodeling/threatmodeling_intro.md)  
+- [**Threat Modeling**](../threatmodeling/threatmodeling_intro.md)  
   You cannot defend against threats you have not imagined. Threat modeling provides the methodological rigour to identify, categorise, and prioritise potential adversaries and their attack paths—early in the design phase. Mastering this discipline turns security from guesswork into an engineering science.
 
-- [**Security Monitoring**](monitoring/monitoring_intro.md)  
+- [**Security Monitoring**](../monitoring/monitoring_intro.md)  
   Even the best designs face novel attacks and insider threats. Monitoring is not about reacting after a breach; it is about designing observable systems that can signal distress in real time. This topic ensures you build for visibility, allowing you to detect anomalies, validate controls, and learn from near-misses continuously.
 
-- [**Security Policies**](policies/policies_intro.md) 
+- [**Security Policies**](../policies/policies_intro.md) 
   Policy is the compass of secure design. Without clear, enforceable rules—on data classification, access control, encryption, and acceptable risk—engineers make inconsistent decisions. You will learn to craft policies that guide behaviour without stifling innovation, and more importantly, how to design systems that enforce policy technically.
 
-- [**Risk Assessment**](riskassesment/ra_intro.md) 
+- [**Risk Assessment**](../riskassesment/ra_intro.md) 
   Perfect security is a myth. Risk assessment is the practical tool that tells you what to protect, to what degree, and at what cost. Mastering this topic enables you to make informed trade-offs, prioritise controls, and speak the language of business leaders—converting technical threats into business risks.
 
-- [**Security Management**](securitymanagement/securitymanagement_intro.md) 
+- [**Security Management**](../securitymanagement/securitymanagement_intro.md) 
   Design does not happen in a vacuum. Security management provides the governance, resource allocation, and oversight needed to embed security across teams and product lifecycles. You will learn how to run security as a management discipline—not a technical afterthought—ensuring accountability from the boardroom to the build server.
 
-- [**Security Principles**](principles/principles_intro.md) 
+- [**Security Principles**](../principles/principles_intro.md) 
   Principles such as least privilege, defence in depth, fail secure, and economy of mechanism are the timeless laws of secure architecture. This topic grounds you in these enduring rules, giving you a mental checklist to evaluate any design decision. When complexity overwhelms, principles guide you back to safe ground.
 
-- [**Security Architecture**](securityarchitecture/architecture_intro.md)
+- [**Security Architecture**](../securityarchitecture/architecture_intro.md)
   Architecture is where principles meet practice. This topic equips you with patterns, reference models, and architectural reviews to design systems that are secure by composition—not by accident. You will learn to layer controls, isolate trust boundaries, and create designs that scale security as they scale functionality.
 
-- [**Secure Software Development Life Cycle (SSDLC)**](ssdlc/ssdlc_intro.md)
+- [**Secure Software Development Life Cycle (SSDLC)**](../ssdlc/ssdlc_intro.md)
   Security by Design must live in the developer’s daily workflow. The SSDLC integrates threat modeling, static analysis, secure coding standards, and security testing into every phase: requirements, design, development, testing, and deployment. Mastering this ensures security is not a gate but a continuous, automated partner in delivery.
 
-- [**Security Culture**](culture/culture_intro.md) 
+- [**Security Culture**](../culture/culture_intro.md) 
   Processes and tools fail if the humans using them are not aligned. Culture is the soil in which security grows. This topic addresses the human factor: fostering psychological safety to report incidents, rewarding secure behaviour, and moving from blame to learning. Without culture, even the best design rots from within.
 
-- [**Open Source Security**](foss/foss_intro.md) 
+- [**Open Source Security**](../foss/foss_intro.md) 
   Modern systems are assembled, not built from scratch. Open source dependencies introduce hidden risks—from known vulnerabilities to supply chain attacks. Mastering this topic teaches you how to vet, monitor, and maintain open source components as rigorously as your own code, turning the ecosystem from a liability into an asset.
 
-- [**Security Training**](training/training_intro.md)
+- [**Security Training**](../training/training_intro.md)
   Finally, design is only as strong as the team that builds it. Security training ensures that every engineer, architect, and product owner possesses the baseline knowledge to make secure decisions. More importantly, advanced training creates internal champions who can guide others. This topic closes the loop from design to continuous human improvement.
 
 In the following lessons, we will explore each of these topics in depth. Do not view them as isolated chapters; instead, see them as interlocking gears. When turned together, they drive the engine of true Security by Design.
diff --git a/monitoring/monitoring_intro.md b/monitoring/monitoring_intro.md
index 33ebad8..5f96ace 100644
--- a/monitoring/monitoring_intro.md
+++ b/monitoring/monitoring_intro.md
@@ -27,11 +27,24 @@ By the end of this section, you will be able to:
 - Distinguish between actionable alerts and noisy, low‑fidelity signals
 - Apply a structured approach to designing, deploying, and operating security monitoring for any system
 
+
++++{"no-pdf": true}
+
 ## Sections
 
 Learn more about security monitoring as a core Security by Design capability in the following sections:
 
-
 :::{toc}
 :context: children
-:::
\ No newline at end of file
+:::
+
++++
+
+
+:::{raw:typst}
+*Sections*
+
+- What is Security Monitoring
+- How to do Security Monitoring
+
+:::
diff --git a/myst.yml b/myst.yml
index e0aa0c8..b2d1b81 100644
--- a/myst.yml
+++ b/myst.yml
@@ -5,7 +5,7 @@ project:
   title: Mastering Security By Design
   description: Security by Design is a proven method to develop products that are less vulnerable for cyber security threats.
   # keywords: []
-  # authors: []
+  #authors:    
   github: https://github.com/nocomplexity/securitybydesign
   license:
     content: CC-BY-SA-4.0  
diff --git a/policies/policies_intro.md b/policies/policies_intro.md
index aa42f53..898faed 100644
--- a/policies/policies_intro.md
+++ b/policies/policies_intro.md
@@ -26,6 +26,9 @@ By the end of this section, you will be able to:
 - Develop or evaluate a software update policy that ensures timely patching without disrupting business operations
 - Apply a Security by Design mindset to create policies that are enforceable, auditable, and scalable across teams
 
+
++++{"no-pdf": true}
+
 ## Sections
 
 Learn more about how security policies enable governance and consistency in Security by Design through the following sections:
@@ -33,4 +36,17 @@ Learn more about how security policies enable governance and consistency in Secu
 
 :::{toc}
 :context: children
-:::
\ No newline at end of file
+:::
+
++++
+
+
+:::{raw:typst}
+*Sections*
+
+- What are Security Policies
+- Design Good Security Policies
+- Protection
+- Checklist for a Software Update Policy
+
+:::
diff --git a/prevention/mvsp.md b/prevention/mvsp.md
index a9eee75..008236e 100644
--- a/prevention/mvsp.md
+++ b/prevention/mvsp.md
@@ -9,13 +9,19 @@ The MVSP is a minimalist security baseline for B2B software and outsourcing part
 
 This checklist distills complex security requirements into the absolute essentials, ensuring your product achieves a baseline of trust and resilience without unnecessary bloat.
 
++++{"no-pdf": true}
+
 :::{toc}
 :context: page
 :::
 
-## 1 Business controls
++++
+%PDF convertion issue towards PDF, so leave ToC for this page out of the PDF version.
+
+
+## Business controls
 
-### 1.1 Vulnerability reports
+### Vulnerability reports
 
 
 - [ ] Publish the method and/or point of contact for security reports on your website. Example: Using the https://securitytxt.org/)[security.txt] standard.
@@ -23,31 +29,31 @@ This checklist distills complex security requirements into the absolute essentia
 - [ ] Respond to reports within a reasonable time frame
 
 
-### 1.2 Customer testing
+### Customer testing
 
 - [ ] On request, enable your customers or their delegates to test the security of your application
 - [ ] Test on a non-production environment that closely resembles the production environment in functionality
 - [ ] Ensure non-production environments do not contain production data
 
-### 1.3 Self-assessment
+### Self-assessment
 
 Perform annual (at a minimum) security self-assessments using the latest MVSP release
 
-### 1.4 External testing
+### External testing
 
 Contract a security vendor to perform annual, comprehensive penetration tests on your systems
 
-### 1.5 Training
+### Training
 
 Implement role-specific security training for your personnel that is relevant to their business function
 
-### 1.6 Compliance
+### Compliance
 
 - [ ] Comply with all industry security standards relevant to your business such as PCI DSS, HITRUST, ISO27001, and SSAE 18
 - [ ] Comply with local laws and regulations in jurisdictions applicable to your company and your customers, such as GDPR, Binding - [ ] Corporate Rules, and Standard Contractual Clauses
 - [ ] Ensure data localization requirements are implemented in line with local regulations and contractual obligations
 
-### 1.7 Incident handling
+### Incident handling
 
 - [ ] Notify relevant parties about any security breach that affects personal data without undue delay, no later than 72 hours upon discovery
   
@@ -57,17 +63,17 @@ Include the following information in the notification:
 * Consequences of the breach
 * Measures taken, or needing to be taken, to remediate the issue
 
-### 1.8 Data handling
+### Data handling
 
 Ensure media sanitization processes based on NIST SP 800-88 (or equivalent) are implemented for storage media holding unencrypted production data
 
-## 2 Application design controls
+## Application design controls
 
-### 2.1 Single Sign-On
+### Single Sign-On
 
 Implement single sign-on using modern, maintained, and industry standard protocols
 
-### 2.2 HTTPS-only
+### HTTPS-only
 
 * Redirect traffic from HTTP protocol (port 80) to HTTPS (port 443)
 
@@ -78,7 +84,7 @@ This does not apply to secure protocols designed to run on top of unencrypted co
 
   * Set authentication cookies as Secure
 
-### 2.3 Security Headers
+### Security Headers
 
 Apply appropriate security headers to reduce the application attack surface and limit post exploitation:
 
@@ -87,7 +93,7 @@ Apply appropriate security headers to reduce the application attack surface and
     or CSP frame-ancestors
 - [ ] Disable caching for APIs and endpoints that return sensitive data
 
-### 2.4 Password policy
+### Password policy
 
 If password authentication is used in addition to single sign-on:
 
@@ -99,18 +105,18 @@ If password authentication is used in addition to single sign-on:
 - [ ] Store passwords in a hashed and salted format using a memory-hard or CPU-hard one-way hash function
 - [ ] Enforce appropriate account lockout and brute-force protection on account access
 
-### 2.5 Security libraries
+### Security libraries
 
 Use modern, maintained, and industry standard frameworks, template languages, or libraries that systemically address implementation weaknesses by escaping the outputs and sanitizing the inputs
 
   Example: ORM for database access, UI framework for rendering DOM
 
-### 2.6 Dependency Patching
+### Dependency Patching
 
 - [ ] Ensure third-party dependencies are maintained and up-to-date, with security relevant updates having a severity score of "medium" or higher applied in line with your application patching schedule
 - [ ] Where dependency patching or upgrades are not possible, equivalent mitigations should be implemented for all components of the application stack
 
-### 2.7 Logging
+### Logging
 
 Keep logs of:
 
@@ -122,21 +128,21 @@ Keep logs of:
 Logs must include user ID, IP address, valid timestamp, type of action performed, and object of this action.
 Logs must be stored for at least 30 days, and should not contain sensitive data or payloads.
 
-### 2.8 Encryption
+### Encryption
 
 Use modern, maintained, and industry standard means of encryption to protect sensitive data in transit between systems, and at rest in online data storages and backups
 
-## 3 Application implementation controls
+## Application implementation controls
 
-### 3.1 List of data
+### List of data
 
 Maintain a list of sensitive data types that the application is expected to process
 
-### 3.2 Data flow diagram
+### Data flow diagram
 
 Maintain an up-to-date diagram indicating how sensitive data reaches your systems and where it ends up being stored
 
-### 3.3 Vulnerability prevention
+### Vulnerability prevention
 
 Train your developers and implement development guidelines to prevent at least the following vulnerabilities:
 
@@ -147,18 +153,18 @@ Train your developers and implement development guidelines to prevent at least t
 - [ ] Cross-site request forgery. Example: Accepting requests with an Origin header from a different domain
 - [ ] Handling untrusted data. Example: Reusing data supplied by users within sensitive application contexts
 
-### 3.4 Time to fix vulnerabilities
+### Time to fix vulnerabilities
 
 Produce and deploy patches to address application vulnerabilities that materially impact security within 90 days of discovery
 
-### 3.5 Build and release process
+### Build and release process
 
 - [ ] Must use a version control system and consistent build process that generates provenance describing how the artifact was built (https://slsa.dev/spec/v1.0/levels#build-l1[SLSA Build Level 1])
 - [ ] Sensitive application credentials and tokens should be stored separately from the application's source code
 
-## 4 Operational controls
+## Operational controls
 
-### 4.1 Physical access
+### Physical access
 
 Validate the physical security of relevant facilities by ensuring the following controls are in place:
 
@@ -167,19 +173,19 @@ Validate the physical security of relevant facilities by ensuring the following
 - [ ] Entry and exit logs
 - [ ] Appropriate response plan for unauthorized access
 
-### 4.2 Logical access
+### Logical access
 
 - [ ] Limit sensitive data access exclusively to users with a legitimate need. The data owner must authorize such access
 - [ ] Deactivate redundant accounts and expired access grants in a timely manner
 - [ ] Perform regular reviews of access to validate need to know
 - [ ] Ensure remote access to customer data or production systems requires the use of Multi-Factor Authentication
 
-### 4.3 Subprocessors
+### Subprocessors
 
 - [ ] Maintain a list of third-party companies with access to customer data, and make it available to clients and business partners upon request
 - [ ] Assess third-party companies annually against the latest MVSP release
 
-### 4.4 Backup and Disaster recovery
+### Backup and Disaster recovery
 
 - [ ] Securely backup all data to a **different location** than where the application is running
 - [ ] Maintain and test disaster recovery plans in concert with your incident response planning, at least annually or after significant changes
diff --git a/prevention/prevention_intro.md b/prevention/prevention_intro.md
index c8576cb..c4bfd81 100644
--- a/prevention/prevention_intro.md
+++ b/prevention/prevention_intro.md
@@ -26,6 +26,9 @@ By the end of this section, you will be able to:
 - Recognise and mitigate supply chain risks using an open software supply chain attack reference checklist
 - Implement a checklist of prevention measures to embed security controls at design, development, and deployment stages
 
+
++++{"no-pdf": true}
+
 ## Sections
 
 Learn more about why prevention is key when practising Security By Design in the following sections:
@@ -33,3 +36,19 @@ Learn more about why prevention is key when practising Security By Design in the
 :::{toc}
 :context: children
 :::
+
++++
+
+
+:::{raw:typst}
+*Sections*
+
+- Why Prevention
+- Shift Left
+- Ransomware
+- Preventing Zero-Day Attacks
+- Checklist:Minimum Viable Secure Product
+- Open Software Supply Chain Attack Reference Checklist
+- Checklist Prevention measurements
+
+:::
diff --git a/prevention/zerodays.md b/prevention/zerodays.md
index 09463a3..3fcc940 100644
--- a/prevention/zerodays.md
+++ b/prevention/zerodays.md
@@ -12,7 +12,7 @@ To prevent zero-day attacks, you should:
 
 * Develop [threat models](../threatmodeling/threatmodeling_intro.md) for all key processes.
 * Implement a process for continuous risk analysis of key processes, utilizing available threat models.
-* Maintain a [security architecture](architecture.md) that's continuously updated and based on solid security principles.
+* Maintain a [security architecture](../securityarchitecture/architecture_intro.md) that's continuously updated and based on solid security principles.
 * Ensure that obvious security principles, such as [Zero Trust](https://nocomplexity.com/documents/securityarchitecture/architecture/NCSC-zerotrustprinciples.html#ncsc-zero-trust-principles), are followed and enforced.
 * Practice and plan for disasters through robust Business Continuity and Disaster Recovery (BCDR) Planning. Have measures in place to ensure critical operations remain functional, helping to prevent bankruptcy.
 
diff --git a/principles/principles_intro.md b/principles/principles_intro.md
index 2805b5e..58952ea 100644
--- a/principles/principles_intro.md
+++ b/principles/principles_intro.md
@@ -19,10 +19,25 @@ By the end of this section, you will be able to:
 
 - Recognise and apply all key Security by Design principles
 
++++{"no-pdf": true}
+
 ## Sections
 
+
 :::{toc}
 :context: children
 :::
 
++++
+
+:::{raw:typst}
+*Sections*
+
+- What is a Security Principle
+- Crucial and Vital Security by Design Principles
+- Example Applying Security Principles for SAST testing
+
+:::
+
+
 
diff --git a/principles/securityprinciples.md b/principles/securityprinciples.md
index 765b294..4777558 100644
--- a/principles/securityprinciples.md
+++ b/principles/securityprinciples.md
@@ -110,6 +110,25 @@ Systems must be able to receive and apply security patches safely and reliably.
 If you think a principle is not applicable for your situation: **Think again.** Or better write down your motivation and ask for an expert review on your motivation.
 
 
+## Cheat sheet
+
+
+| Principle | Summary | Key Rule |
+| --- | --- | --- |
+| **Minimise attack surface area** | Remove unnecessary features, endpoints, entry points. | Less code → fewer holes. |
+| **Establish secure defaults** | Default configs must be secure out-of-the-box. | Deny by default. |
+| **Least privilege** | Every component/user gets minimum privileges to function. | Keep once, not twice. |
+| **Separation of duties** | No single actor has excessive authority. | Split critical functions across multiple actors. |
+| **Defence in depth** | Layer independent security controls. | One failure ≠ system compromise. |
+| **Fail securely** | On failure, default to closed (deny) state. | Never fail open. |
+| **Complete mediation** | Every access request must be checked. | No cached decisions. |
+| **Economy of mechanism** | Keep security-critical designs simple and small. | complexity = **NOT** secure. |
+| **Open design** | No security by obscurity. | Assume attackers have your docs/code. |
+| **Zero Trust** | Never implicitly trust internal/external services. | Verify everything. |
+| **Compartmentalisation** | Isolate components. | Breach in one ≠ breach of all. |
+| **Protect data everywhere** | Encrypt data at rest, in transit, and in-use. | Even during processing. |
+| **Design for secure updates** | Systems must safely apply patches. | Update ability is a security feature. |
+
 ## Learn more
 
 
@@ -120,6 +139,6 @@ These Security by Design principles represent distilled wisdom and long-standing
 ```{tip} Learn more about security principles
 Do not reinvent the wheel by defining your own security principles. Make use of already good defined and battle tested security principles.
 
-In the [Open Security Reference Architecture](https://nocomplexity.com/documents/securityarchitecture/architecture/securityprinciples.html) you can more security principles that can be useful to use or exam.
+In the [Open Security Reference Architecture](https://nocomplexity.com/documents/securityarchitecture/architecture/securityprinciples.html) you can find more security principles that can be useful to use or exam.
 ```
 
diff --git a/riskassesment/ra_intro.md b/riskassesment/ra_intro.md
index efd9250..82d6cd8 100644
--- a/riskassesment/ra_intro.md
+++ b/riskassesment/ra_intro.md
@@ -22,9 +22,24 @@ By the end of this section, you will be able to:
 - Analyse identified risks by estimating likelihood and impact using qualitative scales
 - Produce a prioritised risk list that can directly inform security control selection
 
+
++++{"no-pdf": true}
+
 ## Sections
 
 
 :::{toc}
 :context: children
-:::
\ No newline at end of file
+:::
+
++++
+
+
+
+:::{raw:typst}
+*Sections*
+
+- What is a Risk Assessment
+- Risk Identification and Analysis
+
+:::
diff --git a/riskassesment/riskidentification.md b/riskassesment/riskidentification.md
index 94ba766..756f13c 100644
--- a/riskassesment/riskidentification.md
+++ b/riskassesment/riskidentification.md
@@ -66,7 +66,7 @@ Explained similarly: The expected value of coming up heads on a coin flip is 50%
 ### Probability
 The probability (`p`) of an event could come from a variety of places. Let's use an example scenario of a fire taking place at a chosen museum next year.
 
-Where would we gather a probability of this happening for use in analysis? The answer takes some creativity and some resourcefulness. There may be statistical data on fires at museums you could manually collect. Maybe the insurance company provides their estimate based on claims data. Perhaps risk managing employees at the museum perfomed a study and were [elicited](/risk-measurement/docs/estimation/expert-elicitation) for a probability.
+Where would we gather a probability of this happening for use in analysis? The answer takes some creativity and some resourcefulness. There may be statistical data on fires at museums you could manually collect. Maybe the insurance company provides their estimate based on claims data. Perhaps risk managing employees at the museum performed a study and were elicited for a probability.
 
 You'll notice from these examples that probability is _subjective_! Even if we were to statistically calculate a likelihood from a useful dataset, it would still be up to us (the subject) to choose this indirect measurement as representative of a future probability. Accepting this data allows this data to suggest furture performance, when we already know that past results do not guarantee future performance. 
 
@@ -108,7 +108,7 @@ However, we will always operate with models (quantitative or not) and cannot esc
 ### Impact
 Impact `i` represents losses. It could be as simple as a `i = 1` to represent an all or nothing event, like death. Or, it could the value of a bank account, the passengers on a plane... or from our previous example: The value of all art in a museum. 
 
-However, impact is another probabilistic value with varying results. This will be covered in [distributions](/risk-measurement/docs/risk/distributions). Here, let's consider the behavior of some cybersecurity impacts:
+However, impact is another probabilistic value with varying results. Consider the behavior of some cybersecurity impacts:
 
 - The absurd variance involved in breach costs
 - An under-the-radar incident compared to sustained headlines in the press
@@ -116,7 +116,7 @@ However, impact is another probabilistic value with varying results. This will b
 - The amount of customers that may, or may not, churn from an incident.
 - The amount of time fixing a vulnerability.
 
-When impact is a simple value-at-rest, like a bank account... it can simply be represented by that value. When impact behaves probabilistically, we can resort to writing code as a [monte carlo](/risk-measurement/docs/risk/monte-carlo) simulation.
+When impact is a simple value-at-rest, like a bank account... it can simply be represented by that value. When impact behaves probabilistically, we can resort to writing code as a monte carlo simulation.
 
 It's OK to _assume_ that a scenario will take place and focus on studying its impact, just like it's OK to assume that an incident is bad enough to warrant a study of its causes.
 
diff --git a/securityarchitecture/architecture_intro.md b/securityarchitecture/architecture_intro.md
index 57b0886..3486108 100644
--- a/securityarchitecture/architecture_intro.md
+++ b/securityarchitecture/architecture_intro.md
@@ -29,11 +29,29 @@ By the end of this section, you will be able to:
 - Design security logging mechanisms that support monitoring, detection, and forensic analysis
 - Develop a practical Security Architecture example, including an RBAC outline
 
-### Sections
 
-In the following section you learn how to create a Security Architecture:
++++{"no-pdf": true}
+
+## Sections
 
 
 :::{toc}
 :context: children
-:::
\ No newline at end of file
+:::
+
++++
+
+
+:::{raw:typst}
+*Sections*
+
+In the following section you learn how to create a Security Architecture:
+
+- Security Architecture - What and How
+- Common Security Architecture Building Blocks
+- Steps to Create a Security Architecture
+- Zero Trust Architecture and Security By Design
+- Security Logging
+- Security Architecture Example
+- Example Architecture - RBAC outline
+:::
diff --git a/securityarchitecture/example1.md b/securityarchitecture/example1.md
index aa695fa..bcca4db 100644
--- a/securityarchitecture/example1.md
+++ b/securityarchitecture/example1.md
@@ -23,9 +23,9 @@ Example: SkyLink Security Architecture
 ---
 
 
-## 1. Overview
+## Overview
 
-### 1.1 Purpose
+### Purpose
 
 This document describes the security architecture of the SkyLink platform using Data Flow Diagrams (DFD) to illustrate:
 
@@ -34,7 +34,7 @@ This document describes the security architecture of the SkyLink platform using
 - What security controls are applied at each boundary
 - How data is classified and protected
 
-### 1.2 Scope
+### Scope
 
 This architecture covers:
 
@@ -45,7 +45,7 @@ This architecture covers:
 - PostgreSQL Database (persistent storage)
 - External integrations (WeatherAPI, Google People API)
 
-### 1.3 Audience
+### Audience
 
 - Security Engineers (threat modeling, penetration testing)
 - Developers (secure implementation guidance)
@@ -54,9 +54,9 @@ This architecture covers:
 
 ---
 
-## 2. System Context (Level 0)
+## System Context (Level 0)
 
-### 2.1 Context Diagram
+### Context Diagram
 
 ```
 ┌─────────────────────────────────────────────────────────────────────────┐
@@ -127,7 +127,7 @@ This architecture covers:
 └─────────────────────────────────────────────────────────────────────────┘
 ```
 
-### 2.2 External Actors
+### External Actors
 
 | Actor | Description | Authentication | Data Exchanged |
 |-------|-------------|----------------|----------------|
@@ -138,9 +138,9 @@ This architecture covers:
 
 ---
 
-## 3. Trust Boundaries
+## Trust Boundaries
 
-### 3.1 Boundary Definitions
+### Boundary Definitions
 
 | ID | Boundary | From | To | Risk Level |
 |----|----------|------|-----|------------|
@@ -149,7 +149,7 @@ This architecture covers:
 | **TB3** | Services → External APIs | Internal | External (Vendors) | **HIGH** |
 | **TB4** | Services → Database | Internal | Data Layer | **HIGH** |
 
-### 3.2 Security Controls per Boundary
+### Security Controls per Boundary
 
 #### TB1: Internet → Gateway (CRITICAL)
 
@@ -264,9 +264,9 @@ This architecture covers:
 
 ---
 
-## 4. Data Flow Diagrams (Level 1)
+## Data Flow Diagrams (Level 1)
 
-### 4.1 Flow 1: Aircraft Authentication
+### Flow 1: Aircraft Authentication
 
 ```
 ┌──────────────┐                              ┌──────────────┐
@@ -316,7 +316,7 @@ This architecture covers:
 - [x] JWT RS256 signing (2048-bit RSA)
 - [x] Short token expiry (15 minutes)
 
-### 4.2 Flow 2: Telemetry Ingestion
+### Flow 2: Telemetry Ingestion
 
 ```
 ┌──────────────┐              ┌──────────────┐              ┌──────────────┐
@@ -391,7 +391,7 @@ This architecture covers:
 | 403 | Forbidden | CN ≠ JWT.sub |
 | 429 | Too Many Requests | Rate limit exceeded |
 
-### 4.3 Flow 3: Weather Query
+### Flow 3: Weather Query
 
 ```
 ┌──────────────┐      ┌──────────────┐      ┌──────────────┐      ┌──────────────┐
@@ -445,7 +445,7 @@ This architecture covers:
 - API key never exposed to clients
 - Demo mode prevents external API calls during testing
 
-### 4.4 Flow 4: Contacts OAuth
+### Flow 4: Contacts OAuth
 
 ```
 ┌──────────────┐   ┌──────────────┐   ┌──────────────┐   ┌──────────────┐
@@ -495,9 +495,9 @@ This architecture covers:
 
 ---
 
-## 5. Security Controls by Layer
+## Security Controls by Layer
 
-### 5.1 Control Matrix
+### Control Matrix
 
 | Layer | Control | Implementation | File | Status |
 |-------|---------|----------------|------|--------|
@@ -520,7 +520,7 @@ This architecture covers:
 | **Supply Chain** | SBOM | CycloneDX | `.github/workflows/ci.yml` | :white_check_mark: |
 | **Supply Chain** | Secret detection | Gitleaks | `.github/workflows/ci.yml` | :white_check_mark: |
 
-### 5.2 Defense in Depth Visualization
+### Defense in Depth Visualization
 
 ```
 ┌─────────────────────────────────────────────────────────────────────────┐
@@ -567,9 +567,9 @@ This architecture covers:
 
 ---
 
-## 6. Data Classification
+## Data Classification
 
-### 6.1 Classification Matrix
+### Classification Matrix
 
 | Data Type | Classification | At Rest | In Transit | In Logs | Retention |
 |-----------|----------------|---------|------------|---------|-----------|
@@ -582,7 +582,7 @@ This architecture covers:
 | mTLS Certificates | Restricted | File (0600) | TLS | **Never** | 1 year |
 | API Keys | **Restricted** | Env var | TLS | **Never** | Until rotated |
 
-### 6.2 Data Handling Rules
+### Data Handling Rules
 
 ```
 ┌─────────────────────────────────────────────────────────────────────────┐
@@ -617,9 +617,9 @@ This architecture covers:
 
 ---
 
-## 7. Attack Surface Analysis
+## Attack Surface Analysis
 
-### 7.1 Attack Surface Map
+### Attack Surface Map
 
 | Surface | Exposure | Risk Level | Attack Vectors | Mitigations |
 |---------|----------|------------|----------------|-------------|
@@ -630,7 +630,7 @@ This architecture covers:
 | **CI/CD Pipeline** | GitHub/GitLab | **HIGH** | Secret theft, code injection | Gitleaks, protected branches |
 | **External APIs** | Outbound | **MEDIUM** | Data leakage | HTTPS, minimal data sharing |
 
-### 7.2 Exposed Endpoints
+### Exposed Endpoints
 
 | Endpoint | Authentication | Rate Limited | Input Validation | Risk |
 |----------|----------------|--------------|------------------|------|
@@ -643,9 +643,9 @@ This architecture covers:
 
 ---
 
-## 8. Cryptographic Inventory
+## Cryptographic Inventory
 
-### 8.1 Algorithms and Key Sizes
+### Algorithms and Key Sizes
 
 | Purpose | Algorithm | Key Size | Rotation Period | Storage |
 |---------|-----------|----------|-----------------|---------|
@@ -657,7 +657,7 @@ This architecture covers:
 | mTLS Client | RSA/X.509 | 2048-bit | 1 year | File (certs/clients/) |
 | Image Signing | ECDSA (Sigstore) | P-256 | Keyless (per-build) | GitHub OIDC |
 
-### 8.2 Key Management
+### Key Management
 
 ```
 ┌─────────────────────────────────────────────────────────────────────────┐
@@ -689,9 +689,9 @@ This architecture covers:
 
 ---
 
-## 9. Network Security
+## Network Security
 
-### 9.1 Network Topology
+### Network Topology
 
 ```
 ┌─────────────────────────────────────────────────────────────────────────┐
@@ -730,7 +730,7 @@ This architecture covers:
 └─────────────────────────────────────────────────────────────────────────┘
 ```
 
-### 9.2 Network Policies
+### Network Policies
 
 | Service | Allowed Inbound | Allowed Outbound |
 |---------|-----------------|------------------|
@@ -740,7 +740,7 @@ This architecture covers:
 | contacts | gateway | Google APIs (HTTPS), db:5432 |
 | db | contacts | None |
 
-### 9.3 Kubernetes Network Policies
+### Kubernetes Network Policies
 
 For production Kubernetes deployments, network policies enforce zero-trust networking:
 
@@ -771,16 +771,6 @@ See [KUBERNETES.md](KUBERNETES.md) for full network policy configuration.
 
 ---
 
-## 10. References
-
-### 10.1 Internal Documents
-
-
-### 10.2 External References
-
-
-## Appendix A: References
-
 ### Security Headers
 
 ```http
@@ -815,7 +805,7 @@ Permissions-Policy: geolocation=(), microphone=(), camera=()
 | `maintenance` | Maintenance | telemetry:read/write, config:read |
 | `admin` | Administrator | All permissions |
 
-See [****] for a complete RBAC documentation.
+
 
 ### Rate Limits
 
diff --git a/securityarchitecture/securityarchitecture.md b/securityarchitecture/securityarchitecture.md
index dc5ba12..c742ec7 100644
--- a/securityarchitecture/securityarchitecture.md
+++ b/securityarchitecture/securityarchitecture.md
@@ -91,10 +91,6 @@ Each **ABB** maps to one or more **SBBs**:  Some example SBBs are:
 The entire flow delivers a **secure-by-design** asset, not just a checklist.
 
 
-Here's an improved version of your UK English text, refined for clarity, professional tone, and pedagogical flow in a "Mastering Security By Design" course.
-
-
-
 ## Key learning points
 
 - **Never start with Solution Building Blocks (SBBs)** – Avoid jumping straight to tools such as “we’ll use AWS KMS” without first establishing the underlying security rationale.
diff --git a/securitymanagement/securitymanagement_intro.md b/securitymanagement/securitymanagement_intro.md
index e67ec76..52d4123 100644
--- a/securitymanagement/securitymanagement_intro.md
+++ b/securitymanagement/securitymanagement_intro.md
@@ -25,8 +25,26 @@ By the end of this section, you will be able to:
 - Use a key management template to document, track, and communicate security management activities consistently
 - Explain how security management sustains Security by Design principles throughout the system lifecycle
 
+
++++{"no-pdf": true}
+
 ## Sections
 
+
 :::{toc}
 :context: children
-:::
\ No newline at end of file
+:::
+
++++
+
+
+
+:::{raw:typst}
+*Sections*
+
+- Security Management Aspects
+- Security Framework
+- Mitigate Cyber Risks
+- Key Management Template
+
+:::
diff --git a/sponsors.md b/sponsors.md
index 9ac14be..7ad9f9e 100644
--- a/sponsors.md
+++ b/sponsors.md
@@ -19,6 +19,18 @@ We’ve got an audience of thousands of adopters that read and use our online Pl
 
 Please contact us by [using this page](https://nocomplexity.com/ads-and-sponsoring/) to discuss various options.
 
+:::{include} donate.md
+
+:::
+
+:::{raw:typst}
+*All sponsors will be visible in the online published version of the book Mastering Security By Design.*
+
+:::
+
+
++++{"no-pdf": true}
+
 ## Premium Sponsors
 
 ::::{grid} 2
@@ -53,3 +65,4 @@ Please contact us by [using this page](https://nocomplexity.com/ads-and-sponsori
 
 ::::
 
++++
\ No newline at end of file
diff --git a/ssdlc/ssdlc_intro.md b/ssdlc/ssdlc_intro.md
index 4c28148..f2c0755 100644
--- a/ssdlc/ssdlc_intro.md
+++ b/ssdlc/ssdlc_intro.md
@@ -25,8 +25,24 @@ By the end of this section, you will be able to:
 - Recognise the benefits of a structured, repeatable SSDLC for cross-team alignment and governance
 - Apply core SSDLC practices to build software that is secure by default and resilient over time
 
+
++++{"no-pdf": true}
+
 ## Sections
 
+
 :::{toc}
 :context: children
-:::
\ No newline at end of file
+:::
+
++++
+
+
+:::{raw:typst}
+*Sections*
+
+- What is the Secure Software Development Life Cycle (SDLC)
+- SDLC vs SSDLC
+- SSDL Practices
+
+:::
diff --git a/threatmodeling/stride_example.md b/threatmodeling/stride_example.md
index 2a90047..fbb4121 100644
--- a/threatmodeling/stride_example.md
+++ b/threatmodeling/stride_example.md
@@ -1,4 +1,8 @@
-# Example Threat Model with STRIDE
+---
+title: Example Threat Model with STRIDE
+short_title:  STRIDE Example
+---
+
 
 > **STRIDE-based threat analysis for the SkyLink Connected Aircraft Platform**
 
@@ -17,20 +21,24 @@
 
 ---
 
++++{"no-pdf": true}
+
 ## Table of Contents
 
 :::{toc}
 :context: page
 :::
 
++++
+%PDF convertion issue towards PDF, so leave ToC for this page out of the PDF version.
 
-## 1. Service Description
+## Service Description
 
-### 1.1 Overview
+### Overview
 
 SkyLink is a connected aircraft services platform providing real-time telemetry ingestion, weather data, and contact synchronization for commercial aviation. The platform follows Security by Design principles with multi-layer authentication, defense in depth, and privacy by design.
 
-### 1.2 Functional Decomposition
+### Functional Decomposition
 
 The service provides the following capabilities:
 
@@ -38,7 +46,7 @@ The service provides the following capabilities:
 - **Weather Services**: Geolocation-based weather and air quality data using external APIs
 - **Contact Synchronization**: Google Contacts retrieval via OAuth 2.0 for crew communication
 
-### 1.3 Technical Architecture
+### Technical Architecture
 
 ```
                               Internet
@@ -65,7 +73,7 @@ The service provides the following capabilities:
                                      └─────────────┘
 ```
 
-### 1.4 Component Responsibilities
+### Component Responsibilities
 
 | Component | Responsibility | Security Controls |
 |-----------|---------------|-------------------|
@@ -77,7 +85,7 @@ The service provides the following capabilities:
 
 ---
 
-## 2. Data Dictionary
+## Data Dictionary
 
 List of data stored or in transit within the service.
 
@@ -104,9 +112,9 @@ List of data stored or in transit within the service.
 
 ---
 
-## 3. Threat Actors
+## Threat Actors
 
-### 3.1 External Threat Actors
+### External Threat Actors
 
 | Actor | Motivation | Capability | Target |
 |-------|------------|------------|--------|
@@ -115,7 +123,7 @@ List of data stored or in transit within the service.
 | **Hacktivists** | Ideology, publicity | LOW-MEDIUM | Service availability |
 | **Competitors** | Industrial espionage | MEDIUM | Proprietary data |
 
-### 3.2 Internal Threat Actors
+### Internal Threat Actors
 
 | Actor | Motivation | Capability | Target |
 |-------|------------|------------|--------|
@@ -123,7 +131,7 @@ List of data stored or in transit within the service.
 | **Compromised Account** | Exploited by external | VARIES | Depends on privileges |
 | **Negligent Employee** | None (accidental) | LOW | Misconfigurations |
 
-### 3.3 Supply Chain Threats
+### Supply Chain Threats
 
 | Vector | Risk | Mitigation |
 |--------|------|------------|
@@ -133,9 +141,9 @@ List of data stored or in transit within the service.
 
 ---
 
-## 4. STRIDE Analysis
+## STRIDE Analysis
 
-### 4.1 Spoofing (Identity)
+### Spoofing (Identity)
 
 | ID | Threat | Impact | Likelihood | Mitigation | Status |
 |----|--------|--------|------------|------------|--------|
@@ -145,7 +153,7 @@ List of data stored or in transit within the service.
 | S4 | Stolen aircraft private key | HIGH | Low | HSM storage on aircraft, certificate rotation | :memo: Documented |
 | S5 | JWT token theft | HIGH | Medium | Short expiry (15 min), HTTPS only | :white_check_mark: Implemented |
 
-### 4.2 Tampering (Integrity)
+### Tampering (Integrity)
 
 | ID | Threat | Impact | Likelihood | Mitigation | Status |
 |----|--------|--------|------------|------------|--------|
@@ -156,7 +164,7 @@ List of data stored or in transit within the service.
 | T5 | Log tampering | MEDIUM | Low | Centralized logging (recommended) | :warning: Partial |
 | T6 | Configuration tampering | HIGH | Low | Environment variables, protected branches | :white_check_mark: Implemented |
 
-### 4.3 Repudiation (Non-Repudiation)
+### Repudiation (Non-Repudiation)
 
 | ID | Threat | Impact | Likelihood | Mitigation | Status |
 |----|--------|--------|------------|------------|--------|
@@ -165,7 +173,7 @@ List of data stored or in transit within the service.
 | R3 | Deleted or modified logs | HIGH | Low | Immutable log storage | :x: Not Implemented |
 | R4 | Timestamp manipulation | MEDIUM | Low | Server-side timestamps | :white_check_mark: Implemented |
 
-### 4.4 Information Disclosure (Confidentiality)
+### Information Disclosure (Confidentiality)
 
 | ID | Threat | Impact | Likelihood | Mitigation | Status |
 |----|--------|--------|------------|------------|--------|
@@ -177,7 +185,7 @@ List of data stored or in transit within the service.
 | I6 | Excessive OAuth scope | HIGH | Low | Minimal scope (contacts.readonly) | :white_check_mark: Implemented |
 | I7 | External API data leak (WeatherAPI) | MEDIUM | Low | Geohash/rounding for location | :white_check_mark: Implemented |
 
-### 4.5 Denial of Service (Availability)
+### Denial of Service (Availability)
 
 | ID | Threat | Impact | Likelihood | Mitigation | Status |
 |----|--------|--------|------------|------------|--------|
@@ -188,7 +196,7 @@ List of data stored or in transit within the service.
 | D5 | Database exhaustion | MEDIUM | Low | Connection pooling, limits | :warning: Partial |
 | D6 | CI/CD pipeline failure | HIGH | Medium | Rollback capability | :warning: Partial |
 
-### 4.6 Elevation of Privilege (Authorization)
+### Elevation of Privilege (Authorization)
 
 | ID | Threat | Impact | Likelihood | Mitigation | Status |
 |----|--------|--------|------------|------------|--------|
@@ -200,9 +208,9 @@ List of data stored or in transit within the service.
 
 ---
 
-## 5. Risk Matrix
+## Risk Matrix
 
-### 5.1 Risk Calculation
+### Risk Calculation
 
 **Risk = Impact × Likelihood**
 
@@ -215,7 +223,7 @@ Unlikely        │ LOW          LOW         MEDIUM      HIGH
 Rare            │ ACCEPT       LOW         LOW         MEDIUM
 ```
 
-### 5.2 Current Risk Profile
+### Current Risk Profile
 
 | Risk Level | Count | Examples |
 |------------|-------|----------|
@@ -227,7 +235,7 @@ Rare            │ ACCEPT       LOW         LOW         MEDIUM
 
 ---
 
-## 6. Threat Scenarios
+## Threat Scenarios
 
 Detailed threat scenarios with business impact analysis.
 
@@ -308,7 +316,7 @@ Detailed threat scenarios with business impact analysis.
 
 ---
 
-## 7. Recommendations Summary
+## Recommendations Summary
 
 ### Implemented Controls
 
@@ -333,9 +341,9 @@ Detailed threat scenarios with business impact analysis.
 
 ---
 
-## 8. Gap Analysis
+## Gap Analysis
 
-### 8.1 Current State vs Target State
+### Current State vs Target State
 
 | Control Area | Current | Target | Gap |
 |--------------|---------|--------|-----|
@@ -347,7 +355,7 @@ Detailed threat scenarios with business impact analysis.
 | **Secrets Management** | Environment variables | KMS/Vault | Integration needed |
 | **Incident Response** | None | Documented playbook | Not documented |
 
-### 8.2 Remediation Roadmap
+### Remediation Roadmap
 
 | Phase | Focus | Timeline |
 |-------|-------|----------|
@@ -358,7 +366,7 @@ Detailed threat scenarios with business impact analysis.
 
 ---
 
-## 9. Review History
+## Review History
 
 | Date | Version | Reviewer | Changes |
 |------|---------|----------|---------|
diff --git a/threatmodeling/stride_model.md b/threatmodeling/stride_model.md
index edbf6bf..7eb7896 100644
--- a/threatmodeling/stride_model.md
+++ b/threatmodeling/stride_model.md
@@ -4,7 +4,7 @@ short_title: STRIDE Threat Model
 ---
 
 
-**STRIDE Threat Model**
+## STRIDE Threat Model
 
 
 | **Threat**                 | **Threat Definition**                                                                              |
@@ -23,45 +23,69 @@ short_title: STRIDE Threat Model
 
 :::
 
-## Recommended Threat Modeling Steps
-
-### Step 1: Define security requirements
-
-1. Define security requirements
-2. Create an application diagram
-3. Identify threats
-4. Mitigate threats
-5. Validate that threats have been mitigated
-
-### Step 2: Creating a Simple Design Representation
-
-When applying STRIDE , create a simple representation of your design. Typically, this is done by creating a simple diagram. 
-
-1. Data processes are represented with circles
-2. Data stores are represented with lines above and below their names (you may also see them as cylinders)
-3. Data flows are represented with directed lines; these include data flows over a network
-4. Interactors 
-5. Trust boundaries are represented with a dashed line; these represent the border between trusted and untrusted portions.
 
+## Recommended Threat Modeling Steps
 
-Everything except the trust boundaries, processes, data stores, data flows, and interactors, are considered elements.
-
-The idea is to have a simple model of the design that shows the essential features. Here are some quick rules of thumb for a good representation:
-
-- Every data store should have at least one input and at least one output ("no data coming out of thin air").
-- Only processes read or write data in data stores ("no psychokinesis").
-- Similar elements in a single trust boundary can be collapsed into one element ("make the model simple").
-
-### Step 3: Identify Threats Using STRIDE
-
-When applying STRIDE examine each of the elements (processes, data stores, data flows, and interactors) to determine the threats to which it is susceptible. For each element, you look for the threats as shown in this table:
-
+### **Step 1: Define Scope and Objectives**
+- Clarify the purpose of the threat model (e.g., compliance, design review, risk assessment).
+- Define security requirements and success criteria.
+- Identify stakeholders and their responsibilities.
+
+### **Step 2: Model the System (Decompose the Application)**
+- Create an **application/system diagram** (e.g., Data Flow Diagram, architecture diagram, or even a simple sketch).
+- Document high-level system information, including:
+  - System name
+  - System description and architecture overview
+  - Types and sensitivity of data handled (e.g., PII, financial, health)
+  - Scope and boundaries
+  - External interactions, third parties, and trust boundaries
+  - Primary workflows and use cases
+- Identify assets (what needs protection) and entry/exit points.
+
+**Tip for Step 2 – Using Data Flow Diagrams (DFD):**
+When applying STRIDE, create a simple DFD:
+- **Processes**: Circles or rounded rectangles
+- **Data stores**: Two parallel horizontal lines or cylinders
+- **Data flows**: Directed arrows (including network flows)
+- **External entities / Interactors**: Rectangles
+- **Trust boundaries**: Dashed lines
+
+**Rules of thumb for a good DFD:**
+- Every data store should have at least one input and one output.
+- Only processes can read from or write to data stores.
+- Keep the model simple — combine similar elements within the same trust boundary.
+
+### **Step 3: Identify Threats**
+- Use a structured methodology such as **STRIDE** (or LINDDUN, PASTA, Attack Trees).
+- Brainstorm threats for each element in the model (processes, data flows, data stores, external entities).
+- Consider attacker profiles, motivations, and capabilities.
+- Leverage threat intelligence, OWASP Top 10, CVEs, and past incidents.
+
+**STRIDE Threat Categories:**
+
+| Threat | Property Violated     | Definition |
+|--------|-----------------------|----------|
+| **S**  | Spoofing              | Pretending to be someone/something else |
+| **T**  | Tampering             | Unauthorised modification of data |
+| **R**  | Repudiation           | Denying performing an action |
+| **I**  | Information Disclosure| Exposing information to unauthorised parties |
+| **D**  | Denial of Service     | Making a system unavailable |
+| **E**  | Elevation of Privilege| Gaining higher access rights |
+
+### **Step 4: Assess and Prioritise Risks**
+- Evaluate likelihood and business impact of each threat.
+- Calculate risk levels (qualitative or quantitative).
+- Prioritise based on risk rating and business context.
+
+### **Step 5: Define Mitigations and Countermeasures**
+- Propose security controls for high-priority threats (authentication, encryption, input validation, monitoring, etc.).
+- Assign owners, timelines, and effort estimates.
+- Document residual risk.
+
+### **Step 6: Validate, Review, and Iterate**
+- Review with stakeholders, architects, and security experts.
+- Validate assumptions against the actual implementation.
+- Update the model during design changes or major releases.
+- Maintain findings in a threat model report or register.
+```
 
-| Threat | Property Violated | Threat Definition |
-|--------|-------------------|--------------------|
-| S | Spoofing Identity | Authentication | Pretending to be something or someone other than yourself |
-| T | Tampering with Data | Integrity | Modifying something on disk, network, memory, or elsewhere |
-| R | Repudiation | Non-repudiation | Claiming that you didn't do something or were not responsible; can be honest or false |
-| I | Information Disclosure | Confidentiality | Providing information to someone not authorized to access it |
-| D | Denial of Service | Availability | Exhausting resources needed to provide service |
-| E | Elevation of Privilege | Authorization | Allowing someone to do something they are not authorized to do |
\ No newline at end of file
diff --git a/threatmodeling/threatmodeling_intro.md b/threatmodeling/threatmodeling_intro.md
index bc43dae..c1da9d3 100644
--- a/threatmodeling/threatmodeling_intro.md
+++ b/threatmodeling/threatmodeling_intro.md
@@ -23,8 +23,26 @@ By the end of this section, you will be able to:
 
 ---
 
-## Sections 
++++{"no-pdf": true}
+
+## Sections
+
 
 :::{toc}
 :context: children
-:::
\ No newline at end of file
+:::
+
++++
+
+
+
+:::{raw:typst}
+*Sections*
+
+- What is Threat Modeling
+- STRIDE Threat Model
+- Example Threat Model with STRIDE
+
+:::
+
+