Appendices are where all the “show me” evidence lives: the model, detailed quotes, legal notes, architecture, and reviews that back up the story in the main document. Used well, they make your case robust without bloating the narrative. Used badly, they confuse reviewers and hide key facts where nobody will see them.
This chapter explains what must be attached, how to structure your data book and model documentation, how to capture assurance and independent review notes, and how to assemble appendices step by step—ending with a practical checklist you can use before submission.
17.1 Required Attachments (Quotes, Legal, Security, Privacy)
Think of required attachments as the “audit trail” of your business case. They don’t belong in the main story, but they must exist and be easy to find.
You’ll typically need attachments in four broad families:
- Commercial / vendor evidence
- Legal and regulatory notes
- Security, privacy, and risk controls
- Technical / architectural support
Depending on decision size and risk profile, some can be light; others will be mandatory.
Commercial and vendor attachments
These support your cost model and vendor choices:
- Vendor proposals and quotes used in your TCO.
- Rate cards, discount structures, and volume tiers.
- Summary of bid evaluation (if you ran a competitive process).
- Any letters of intent (LOIs) or term sheets, clearly marked as non-binding where applicable.
Key practices:
- Include a short cover sheet that lists: vendors evaluated, final choice, headline commercial terms, and key assumptions (volumes, term length, currency).
- Redact or separate genuinely confidential commercial secrets if the pack has broad circulation, but note where full details can be accessed.
Legal and regulatory attachments
For non-trivial initiatives, legal and regulatory input should be documented—even if the conclusion is “low concern.”
Typical contents:
- Legal opinion or note on key issues (contract structure, liability, IP, jurisdiction, regulatory perimeter).
- Regulatory alignment memo (e.g., mapping to relevant regulations, required notifications/approvals).
- Draft or final contract skeleton where deal structure itself is a decision point (e.g., JV agreements, long-term outsourcing contracts).
You do not need every clause in the appendix, but you do need a summary note that answers:
- Are there any deal breakers or “red lines”?
- Are there any mandatory steps (approvals, filings) that affect the schedule?
- Are there unusual liabilities or exposures the decision body must explicitly accept?
Security, privacy, and risk-control attachments
These are increasingly non-negotiable, especially for tech, data, or customer-facing changes.
Common content:
- Information security assessment (e.g., cyber risk review, penetration test plan/results, control matrix).
- Data protection / privacy impact assessment (DPIA), if processing personal data is involved.
- Control design summary (key controls, owners, testing plan).
- Any correspondence with regulators about security/privacy aspects, if relevant.
The main business case should refer to a one-page summary of findings; the detailed assessment sits in the appendix.
Technical and architectural attachments
Use when technology, integration, or infrastructure decisions are material:
- High-level architecture diagram and component descriptions.
- Integration landscape and system decommissioning plan.
- Capacity, performance, and resilience assumptions (e.g., sizing documents).
- Technology standards or patterns referenced (e.g., “compliant with our cloud reference architecture”).
Keep these at executive-readable depth; deeply technical specs should live in separate design repositories, not in the business case pack.
17.2 Data Book and Model Documentation
The data book and model documentation are the heart of your analytical transparency. They allow finance, risk, and auditors to reconstruct your numbers and challenge assumptions without reverse-engineering a messy spreadsheet.
Data book: what it is
The data book is a curated bundle of:
- Source tables: key inputs used to build baselines and drivers (e.g., historic volume, cost, incident, and performance data).
- Transformations: how raw data was cleaned or aggregated for use in the model.
- External benchmarks: selected excerpts or tables from third-party sources, with context.
- Pilot / experiment results: KPIs and outcomes from tests that underpin assumptions.
It is not every raw extract from every system. It’s the minimal set needed to understand and validate your case.
Practical structure (can be one PDF or a small set of files):
- Cover page: initiative name, owner, version/date.
- Contents: list of tables/sections and where they’re used (e.g., “Table 3: Baseline FTE by process → used in model tab 05_Benefits, cells …”).
- Internal data: each with description, time period, and source (system/report ID).
- External benchmarks: each with citation and any normalization steps.
- Pilot results: design summary and key metrics with comparison to baseline.
Model documentation: what reviewers need
Model documentation should let a competent finance partner understand structure and logic in under an hour.
At minimum:
- Purpose and scope: What the model does and does not cover; horizon; currency; discount rate.
- Sheet map: Short description of each tab (e.g., “02_Assumptions: global drivers by scenario; 05_Benefits: detailed benefit calculations by driver”).
- Driver dictionary: Definitions of key drivers and how they are used.
- Formula logic: High-level description of how cash flows, NPV, IRR, and payback are computed.
- Scenario and sensitivity logic: Which assumptions change, where scenarios are configured, how sensitivities work.
- Known limitations: Areas of simplification (e.g., approximate tax, assumed linear ramp, proxy measures) and why they are acceptable.
This can be a short Word/Docx appendix or a dedicated “Guide” tab in the model, referenced in the business case.
Traceability between data, model, and narrative
Make it easy to go from:
- A headline in the case (“labor savings of $6.8m by FY28”)
→ to the benefit line in the model
→ to the source data and assumptions in the data book.
You don’t need a perfect cross-reference system, but you should:
- Use consistent naming across data book, model, and narrative.
- Flag in the data book which dataset supports which benefits or cost lines.
- In the model, comment or label key cells with references to data book tables or assumption IDs.
If an external reviewer cannot reconstruct your logic in an afternoon, the documentation is too thin.
17.3 Assurance and Independent Review Notes
As stakes rise, decision-makers look for independent challenges. Assurance notes prove that others have kicked the tires.
Depending on context, assurance can come from:
- Finance / controlling
- Risk and compliance
- Internal audit
- Information security / data privacy
- Architecture / CTO office
- External advisors (for M&A, major technology, or regulatory cases)
What assurance notes should contain
Each assurance note, however brief, should answer:
- Scope of review – What did we look at, and what did we not look at?
- Key findings – Where are we comfortable, where do we see weakness?
- Conditions or recommendations – Any conditions for approval, or follow-ups required.
- Conclusion – Overall assessment (e.g., “no major issues”, “conditionally acceptable”, “not recommended without material changes”).
These notes can be short (one page per function) unless the initiative is very large.
Examples:
- Finance note: Confirming structure of the model, key assumptions, alignment with accounting policies, and absence of major arithmetic or consistency errors.
- Risk/compliance note: Confirming risk taxonomy coverage, mitigation design, residual risk vs appetite, and any mandatory controls.
- Security note: Confirming that architecture and controls meet security standards; highlighting any exceptions.
- Internal audit note: For very large or sensitive initiatives, a pre-implementation assurance visit.
Where to place assurance in the pack
- In the main body: a short summary box listing who has reviewed and headline conclusions (e.g., “Finance: model reviewed and accepted; Risk: residual risk within appetite subject to condition X”).
- In the appendix: full assurance notes or memos.
Make sure dates and versions line up with the rest of the case; if the model or design changed after a review, either:
- Get a refreshed sign-off, or
- Clearly note limitations (“Finance review conducted on v0.9 model; no material changes to structure since then”).
17.4 Step-by-Step Appendices Assembly Guide
Rather than treating appendices as “whatever’s left at the end,” treat them as a structured package. Here’s a practical sequence.
Step 1 – Decide what belongs in the main body vs appendices
Revisit the core case:
- Anything critical for the decision but short → main body (with brief references to detail in appendices).
- Anything supportive evidence or deep detail → appendices.
Make a simple table (for yourself) of sections and supporting artifacts.
Step 2 – Create an appendix map
Before collecting files, define an outline such as:
- Appendix A – Assumptions log
- Appendix B – Financial model guide and key outputs
- Appendix C – Data book (internal and external data)
- Appendix D – Risk register and control design
- Appendix E – Architecture and technical notes
- Appendix F – Vendor commercial analysis and quotes
- Appendix G – Legal/regulatory assessments
- Appendix H – Security and privacy assessments
- Appendix I – Benefits register and tracking plan
- Appendix J – Assurance and independent reviews
You will not need all of these for every case. Cross out what doesn’t apply, combine smaller ones where appropriate, and add any specialized items (e.g., ESG impact analysis, public consultation summaries).
Step 3 – Standardize file naming and versioning
To avoid chaos:
- Use a consistent naming convention, for example:
- CaseName_AppendixA_AssumptionsLog_v1.2_2025-11-20.xlsx
- CaseName_AppendixF_VendorQuotes_v1.0_2025-11-18.pdf
- Keep a master list in a short “Appendix Index” page in the main document or a separate PDF, listing:
- Appendix ID (A, B, etc.)
- Title
- File name
- Owner
- Version/date
This saves reviewers from hunting through folders or email chains.
Step 4 – Assemble the model and data book
- Place the decision version of the model in a clearly labeled folder (e.g., /Financials/Final_Model/).
- Create or finalize the Guide tab or separate model documentation note.
- Compile the data book as a clearly indexed PDF or set of tabs in a separate workbook, with sources and notes.
Cross-check that all figures in the main case reference this “final” model version, not earlier drafts.
Step 5 – Attach risk and controls content
- Export the risk register and any control design summary into a neat format (often a PDF render of the register).
- If separate tools (GRC systems) hold risk info, create a snapshot and add a short explanatory cover.
Ensure the main risk section of the case references the appendix (e.g., “See Appendix D for full risk register and control plan”).
Step 6 – Add legal, security, and regulatory notes
- Ask Legal, Security, Privacy, and Compliance to provide short written notes (or confirm that their email notes can be included as-is).
- Place each in the relevant appendix section (e.g., G, H).
- Summarize their conclusions in one paragraph in the main body.
This makes your assurance and approvals auditable later.
Step 7 – Attach vendor and procurement documents
- Select only the relevant pages of vendor proposals (e.g., pricing tables, scope sections) if the full documents are huge, and note where the full versions reside.
- Include the commercial comparison or evaluation summary (if applicable).
- Make sure any confidentiality marks are respected and distribution is appropriate to the audience.
Step 8 – Compile assurance notes
- Collect finance, risk, audit, architecture, and any external advisory notes.
- Add a short cover sheet summarizing: who reviewed, when, and overall conclusion.
- Ensure any conditions from these notes are explicitly repeated in the main recommendation/conditions section.
Step 9 – Final consistency check
Before freezing:
- Check appendix labels in the main document match actual files (e.g., “Appendix C” really is the data book).
- Check all cross-references (“see Appendix F”) work and refer to something that exists.
- Check version numbers and dates across all files for obvious mismatches.
- Remove obsolete or draft attachments from the submission bundle; archive them separately.
Step 10 – Package and share
Depending on your tooling:
- Zip the final bundle with a clear name (e.g., CaseName_DecisionPack_v1.0_2025-11-20.zip).
- For board/executive circulation, consider a one-page cover listing main document + appendices with brief descriptions.
Confirm with the meeting secretary or PMO that file sizes, formats, and distribution lists meet process requirements.
17.5 Appendices Checklist
Use this checklist right before you send the decision pack.
A. Structure and clarity
- Appendices are listed and labelled (A, B, C …) in an index with titles and owners.
- Every “see Appendix X” reference in the main case points to a real, up-to-date attachment.
- File names follow a clear convention and include version and date.
B. Financials and data
- A decision-version financial model is included or accessible, with a guide tab or separate documentation.
- A data book (or equivalent) exists, covering key internal data and external benchmarks used.
- Major numbers in the main case (NPV, IRR, payback, key costs/benefits) can be traced to the model and data book.
C. Risk and controls
- Full risk register is included, with inherent and residual ratings, owners, and mitigations.
- Any control designs, test plans, or monitoring frameworks cited in the case are attached.
- Dependencies and contingencies discussed in the main text have supporting detail where relevant.
D. Legal, regulatory, security, and privacy
- Legal note (or confirmation of low/no issues) is included for material contracts or structural changes.
- Regulatory and compliance assessments (if relevant) are attached or clearly referenced.
- Information security and privacy assessments (if relevant) are attached, including any exceptions or open issues.
E. Vendors and commercial evidence
- Vendor quotes, SOWs, or pricing schedules underpinning cost estimates are included (or summarized with clear references).
- If a competitive process was run, a commercial evaluation summary is attached.
- TCO calculations in the model match vendor documents and assumptions.
F. Technical and architecture
- High-level architecture diagrams and supporting notes are included where technology is material.
- Integration and decommissioning plans cited in the main case have supporting material.
- Any technical capacity/sizing assumptions (e.g., infra, cloud) have evidence or rationale attached.
G. Benefits and measurement
- The benefits register is included, with benefit IDs, owners, formulas, and ramp profiles.
- KPI definitions, baselines, and targets used for benefits tracking are included or clearly referenced.
- Any pilot or experiment results used to justify benefits are attached.
H. Assurance and independent review
- Finance, risk/compliance, security/privacy, architecture, and/or audit notes (as appropriate) are included.
- Any conditions or caveats from assurance notes are clearly restated in the main recommendation.
- Dates and model/design versions in assurance notes match the final case or differences are explained.
I. Version control and hygiene
- Only final or decision-ready versions of attachments are in the submission bundle; drafts are archived separately.
- All attachments use consistent terminology with the main case (option names, initiative title, KPI labels).
- Confidential or sensitive attachments (e.g., detailed contracts, personal data) are handled according to policy and access is limited appropriately.
If you can walk through this checklist and tick the boxes honestly, your appendices and supporting materials will do exactly what they should: provide a clean, auditable backbone for your case, give reviewers confidence in the numbers and the controls, and prevent last-minute “where did this come from?” crises in the approval meeting.
