How to Use This Documentation ============================= This documentation is designed to be used by **engineering teams, security leaders, compliance owners, and auditors** working in regulated or customer-assessed environments. It is not marketing material. It is a **working reference** for architecture, control implementation, evidence generation, and assurance. Who this documentation is for ----------------------------- This documentation is intended for: - Engineering and platform teams implementing security controls - Security and compliance teams preparing for audits or customer assurance - Architects defining cloud and software security foundations - Leadership teams seeking defensible positions for regulators and customers - External auditors and assessors reviewing technical evidence How the documentation is structured ----------------------------------- The documentation is organised around **execution, not theory**. Each section serves a distinct purpose: Start here ^^^^^^^^^^ Orientation material explaining how Thinkwerke approaches security, compliance, and evidence generation. Solutions & Architectures ^^^^^^^^^^^^^^^^^^^^^^^^^ Concrete implementation patterns for secure software delivery, cloud security foundations, vulnerability handling, and detection capabilities. Compliance Mapping ^^^^^^^^^^^^^^^^^^ Translations of regulatory and standard requirements (ISO 27001, NIS2, CRA, GDPR) into **technical controls and evidence expectations**. Evidence Library ^^^^^^^^^^^^^^^^ Examples of audit-ready artifacts, tender packs, questionnaires, and control-to-proof mappings used in real engagements. Whitepapers & Research ^^^^^^^^^^^^^^^^^^^^^^ Deeper analysis and guidance for organisations designing long-term security and compliance strategies. How to read a page ------------------ Most pages follow a consistent structure: - **Context** – why the topic exists and where it applies - **What good looks like** – expected outcomes, not just activities - **Implementation guidance** – how controls are executed in practice - **Evidence expectations** – what proof is typically required - **Common pitfalls** – frequent failure patterns observed in audits What this documentation is not ------------------------------ To avoid confusion, this documentation deliberately does **not** include: - Tool-specific vendor marketing - Generic compliance checklists - One-size-fits-all policies - Legal interpretations of regulations Where tools are referenced, they are used as **examples**, not requirements. How to use this for audits and tenders -------------------------------------- These documents can be used directly to: - Prepare for ISO 27001, NIS2, CRA, or customer audits - Build internal control and evidence libraries - Support tender and procurement responses - Align engineering, security, and compliance teams However, documentation alone is **not evidence**. Auditors and customers will expect implementations, logs, workflows, and traceability behind what is described here. Living documentation -------------------- This documentation evolves based on: - Regulatory changes - Customer and auditor expectations - Lessons learned from real implementations Sections may be expanded, refined, or deprecated over time to reflect current best practices. How to engage Thinkwerke ------------------------ If you are using this documentation and need: - Validation of your current approach - Help implementing the described controls - Audit or tender acceleration - A reference architecture or walkthrough Engage Thinkwerke through the main website or directly via the contact details provided there.