Solution assurance / New record Static starter — entries are not yet saved
Unified DDaT intake

One record from business need to risk acceptance.

Capture shared information once, then use it across the Business Requirements Document, Solution Design Document and Information Risk Assessment Report.

BRD Business requirements SDD Solution design IRAR Information risk
Starter convention: every register and table is intended to be repeatable. Two or three blank rows are shown only to establish the data shape.
Review readiness

0 of 8 areas complete

8 areas still need attention. Complete the essential fields shown for each area; enter N/A where needed.

0%
Across all source documents
Show what still needs attention
    01 · Foundation

    Project & governance

    Establish the shared identity, accountable owners and document control details.

    BRDSDDIRAR
    Shared record

    These details are captured once and reused wherever the three templates ask for the same information.

    Identity

    Initiative details

    Core fields
    Ownership

    Accountable people and teams

    Risk governance

    Decision-making roles

    IRAR
    Change control

    Version history

    BRDSDD
    Document version history
    Version Release date Author Summary / reason
    Continue to business case
    02 · Business context

    Business case & scope

    Describe why the change is needed, who it affects and how success will be recognised.

    BRDSDDIRAR
    Purpose

    Need and intended outcome

    Boundaries

    Scope

    Outcomes

    Indicative benefits

    BRD

    Use the source themes where relevant, or replace them with initiative-specific outcomes.

    Indicative benefits
    Benefit theme Expected outcome Measure / evidence Owner
    Impact

    User groups and business processes

    Impacted user groups

    Impacted user groups
    User group Profile and current use Location / access Expected impact

    People / role impact

    People and role impact
    Role Organisation Change description Change size Impact

    Business process impact

    Business processes affected
    Business process Change description Change size Impact
    Constraints

    Assumptions, dependencies and initial risks

    Assumptions & constraints

    Dependencies

    Initial business risks

    Initial business risks
    Risk ID Risk description Owner Treatment / next step
    Previous Continue to requirements
    03 · Definition

    Requirements

    Maintain one traceable register, supported by data, access, testing and experience detail.

    BRDSDD
    Master register

    Business and solution requirements

    Use unique IDs

    The category preserves the source document groupings while keeping every requirement in one place. MoSCoW values follow the conventional interpretation.

    Business and solution requirements
    ID Category MoSCoW Short name User story / recommendation / requirement Actions
    2 requirement rows

    Quality attributes

    Non-functional requirements

    BRD

    These requirements apply to all functionality unless a scope exception is recorded.

    Data specification

    Request fields and validation

    BRD
    Request form data fields and validation rules
    Field name Mandatory? Type / list Description Validations Help text
    Access

    Roles, permissions and test groups

    Role-based access

    Role based access requirements
    User group Permissions needed

    Test groups

    Testing groups and permissions
    Test group Permissions
    Experience

    Usability and self-service

    Previous Continue to solution & service
    04 · Service context

    Solution & service

    Describe the system, its data, its operating model and the organisations that provide it.

    SDDIRAR
    System

    Overview and usage

    Provision

    Supplier, hosting and resilience

    Prime contractor?
    Adjacent to non-Police systems?
    Disaster recovery?
    Lifecycle

    Status, roadmap and licensing

    Part of an ongoing project?
    On-call support required?
    Support model

    Support environments and contracts

    Connections

    Reliance on other systems

    Connected systems, networks and data flows
    System / service Purpose Network Data in Data out
    Previous Continue to architecture
    05 · Design

    Architecture

    Connect logical intent to the physical components, configuration and dependencies that implement it.

    SDD
    Assumptions

    Design and implementation assumptions

    Logical design

    Application components and interactions

    Elements covered
    Logical application components
    Logical component Role / function Change description Size Impact Physical mapping
    Physical design

    Infrastructure and configuration

    Elements covered
    Physical solution components
    Component Type Environment Specification / configuration Change description Change size Impact

    Include production, development, test and disaster recovery components where they exist.

    Dependencies

    Architecture dependencies and reference designs

    Previous Continue to information risk
    06 · Assurance

    Information risk

    Assess business impact, threats, controls, independent evidence and the risks that remain.

    SDDIRAR
    Governance

    Engagement and oversight

    IRAR
    Background assessment

    Business impact and risk appetite

    Privacy

    Privacy impact

    Privacy impact considered?
    Risk identification

    IS1 and risk workshops

    Risk register

    Threats, controls and residual risk

    Include well-mitigated risks where the potential for significant harm remains, plus service, compliance, personnel and assurance shortfalls.

    Information risk register
    Risk ID Threat / shortfall Potential business harm Controls Residual risk Owner / action
    Assurance assessment

    Controls and independent evidence

    Decision

    Risk acceptance

    Exact IRAR options
    Select the risk decision
    Previous Continue to delivery & operations
    07 · Transition

    Delivery & operations

    Plan implementation, prove the solution works and define the controls needed to run it safely.

    BRDSDDIRAR
    Service management

    Operational assurance

    Cover both the supplier and the project/system-owner “contractee” environment.

    Continuity

    Backup and recovery

    SDD
    Service health

    Per-component monitoring and protection

    Service health controls by component
    Component Monitoring sensors Anti-malware / web reputation On-server firewall Exclusions and allowed / blocked URLs
    Implementation

    Roles, requirements and deliverables

    Implementation roles and deliverables
    Role / owner Deliverable or activity Target date Dependency Status
    Testing

    Functional test record

    Record both planned and completed testing so the system’s health is evidenced before live operation.

    Functional testing plan and evidence
    Test / procedure Group / owner State Result and health evidence External provider? Evidence / sign-off
    Runbooks

    Process documentation

    Procedure coverage to consider
    Process documentation produced
    Document name Notes Team Location
    Previous Continue to evidence & sign-off
    08 · Completion

    Evidence & sign-off

    Connect the supporting evidence, review trail, glossary and final decision in one place.

    BRDSDDIRAR
    Assurance pack

    Information assurance and data security evidence

    Evidence produced or referenced
    References

    Reference documents and useful links

    Reference documents
    Document name Version Document date Owner Location / link Related section

    Attach documents referenced during design, assessment, testing and risk review.

    Useful source reference: ICO guidance on data protection impact assessments.

    Language

    Abbreviations, acronyms and glossary

    BRD

    Keep entries in alphabetical order in the implemented service.

    Abbreviations acronyms and glossary
    Abbreviation / term Description
    Review trail

    Distribution, reviewers and approvers

    Document distribution reviewers and approvers
    Version Name / distributed to Role / representing Relationship Submission date Response date Signed-off Action / info / evidence
    Final check

    Record readiness

    Before review
    End of starter flow

    Ready to connect to a data model and workflow.

    The fields above cover the requested content from all three source templates without reproducing their drafting instructions.

    Previous Back to the start