Skip to content

Templates

Download a blank SAD template from the Downloads page in your preferred format (Word, Markdown, YAML, or JSON).

1. Fill in manually — open the template in your editor, wiki, or word processor and complete each section.

2. Import into an LLM — feed the template to ChatGPT, Claude, or Copilot along with a project brief to generate a structured first draft.

3. Paste into Confluence — copy the Markdown template to your clipboard and paste directly into Confluence, Notion, or any wiki that supports Markdown.

Use Pandoc to convert between formats:

Terminal window
# Markdown to Word
pandoc sad-template.md -o my-sad.docx
# Markdown to ODF (LibreOffice)
pandoc sad-template.md -o my-sad.odt
# With custom branding
pandoc sad-template.md -o my-sad.docx --reference-doc=your-template.docx

ADS is backed by a formal JSON Schema — a machine-readable definition of every section, field, enum, and required relationship in a SAD. If you author your SAD in JSON or YAML, you can run an off-the-shelf validator against the schema to confirm the document is structurally complete and the values are within the expected vocabularies (e.g. that classification is one of public / internal / restricted / highly-restricted).

The validator catches the kinds of mistake that survive a casual review: a missing required field, a typo in an enum value, the wrong type for a field, or a section structurally in the wrong place. It complements human review — it doesn’t replace it.

See Validating a SAD against the Schema on the JSON Schema page for the full Node and Python instructions, plus what a validation error looks like and how to read it. Markdown and Word SADs aren’t directly validatable in this way, but you can convert them to YAML or JSON via Pandoc or a builder tool and validate the result.

You can extend the standard for your organisation without modifying the core sections. There are two extension points:

  • organisationProfile — maps the standard to your internal tools, standards, and governance gates
  • customSections — adds organisation-specific sections (e.g., cloud governance checklists, data privacy assessments)

In YAML or JSON: Add the organisationProfile and/or customSections blocks at the end of your SAD file (after appendices). They sit at the top level, alongside the standard sections.

In Markdown: Add new headings after Section 7 (Appendices) with your custom content. Use the same table format as the rest of the document.

In Word: Add new sections after the Appendices. Follow the same heading and table style.

For your whole organisation: Create a customised template with the organisationProfile pre-filled and distribute it to your architecture teams. This way every new SAD starts with the correct tool mappings and governance gates.

Add this block to the end of your YAML SAD to map the standard to your organisation’s tools and governance:

organisationProfile:
organisationName: "Acme Corp"
tooling:
cmdb: "ServiceNow"
secretStore: "HashiCorp Vault"
monitoring: "Datadog"
siem: "Splunk"
cicd: "GitHub Actions"
portfolioManagement: "LeanIX"
internalStandards:
- id: "STD-001"
name: "Cloud Platform Standards"
version: "2.0"
mappedSections: ["physicalView", "securityView"]
- id: "POL-008"
name: "Information Security Policy"
version: "4.1"
mappedSections: ["securityView", "dataView"]
governanceGates:
- gateName: "Dev/Test Review"
requiredMaturityLevel: "minimum"
requiredSections: ["documentControl", "executiveSummary", "architecturalViews", "riskGovernance"]
- gateName: "Production Approval"
requiredMaturityLevel: "recommended"
requiredSections: ["documentControl", "executiveSummary", "stakeholders", "architecturalViews", "qualityAttributes", "lifecycleManagement", "riskGovernance"]
- gateName: "Enterprise Architecture Review"
requiredMaturityLevel: "comprehensive"
requiredSections: ["documentControl", "executiveSummary", "stakeholders", "architecturalViews", "qualityAttributes", "lifecycleManagement", "riskGovernance", "appendices"]

The same configuration in JSON format:

{
"organisationProfile": {
"organisationName": "Acme Corp",
"tooling": {
"cmdb": "ServiceNow",
"secretStore": "HashiCorp Vault",
"monitoring": "Datadog",
"siem": "Splunk",
"cicd": "GitHub Actions",
"portfolioManagement": "LeanIX"
},
"internalStandards": [
{
"id": "STD-001",
"name": "Cloud Platform Standards",
"version": "2.0",
"mappedSections": ["physicalView", "securityView"]
}
],
"governanceGates": [
{
"gateName": "Dev/Test Review",
"requiredMaturityLevel": "minimum",
"requiredSections": ["documentControl", "executiveSummary", "architecturalViews", "riskGovernance"]
},
{
"gateName": "Production Approval",
"requiredMaturityLevel": "recommended",
"requiredSections": ["documentControl", "executiveSummary", "stakeholders", "architecturalViews", "qualityAttributes", "lifecycleManagement", "riskGovernance"]
}
]
}
}

Add organisation-specific sections without modifying the core standard:

customSections:
- id: "cloud-governance"
title: "Cloud Governance Checklist"
description: "Organisation-specific cloud governance requirements"
maturityLevel: "recommended"
parentSection: "physicalView"
content: |
| Control | Status | Evidence |
|---------|--------|----------|
| Tagging policy applied | Yes / No | |
| Cost alerts configured | Yes / No | |
| Backup policy applied | Yes / No | |
- id: "data-privacy"
title: "Data Privacy Assessment"
description: "GDPR and data privacy specific requirements"
maturityLevel: "recommended"
parentSection: "dataView"
content: |
| Question | Response |
|----------|----------|
| DPIA completed? | Yes / No |
| Data processor agreements in place? | Yes / No |
| Subject access request process documented? | Yes / No |

See Conformance and Usage for full customisation guidelines.