> This is part 1 of 4 of the full documentation (pages 1–100 of 357). > The content is paginated: fetch every part to see all of it. > Next part: https://framework.aic.io/llms-full.txt/1 > Page index: https://framework.aic.io/llms.txt # Company Operating Manual ## Purpose This GitBook explains how we operate as a company. It defines our delivery model, commercial controls, agile approach, governance standards, intellectual property strategy, and the reusable assets we use to accelerate projects. This manual is designed to create a consistent way of working across customers, projects, suppliers, and internal teams. ## Table of Contents * Home ### 1. Company Operating Framework * How We Operate * Operating Principles * Our Delivery Model * Roles, Responsibilities and Accountability * Decision-Making Model ### 2. Commercial and Contractual Model * Commercial Operating Model * Framework Agreements * Statements of Work * Subcontractor Engagement * Change Control * Payments, Milestones and Acceptance ### 3. Agile Delivery Approach * Agile Delivery Overview * Core Agile Principles * Discovery * Alpha * Beta * Live * Retirement * Agile Ceremonies * Backlog, Roadmap and Prioritisation ### 4. Delivery Governance * Governance Overview * Delivery Assurance * Risk and Issue Management * Reporting and Progress Tracking * Project Controls * Acceptance and Sign-Off ### 5. Intellectual Property and Accelerators * IP Strategy * Background IP * Foreground IP * Reusable Assets and Accelerators * Asset Library * IP Reuse Rules * Open Source and Third-Party Components ### 6. Engineering and Technical Standards * Engineering Principles * Architecture Standards * Secure Development * Repository and Version Control Standards * Code Review and Quality Gates * Release and Deployment Standards ### 7. Security, Compliance and Data * Security Operating Model * Data Handling and Classification * Access Control * Audit and Evidence * Information Assurance * Supplier Security Requirements ### 8. People, Suppliers and Onboarding * Team Model * Internal Onboarding * Supplier Onboarding * Ways of Working * Performance Expectations ### 9. Templates and Operating Artefacts * Template Library * Statement of Work Template * Project Initiation Document Template * Weekly Report Template * Milestone Report Template * Change Request Template * Acceptance Certificate Template * Risk and Issue Log Template ### 10. Glossary * Glossary # Company Operating Framework ## Company Operating Manual ### What This Manual Is This manual defines how we operate, deliver, govern, and improve work across customer engagements. It provides one consistent operating system for: * commercial engagement * project delivery * agile working * governance * intellectual property control * technical delivery * security and compliance * supplier management * reusable delivery accelerators ### Why This Exists We operate in complex, high-assurance environments where delivery speed, governance, security, and commercial control must work together. This manual exists to make our operating model repeatable, scalable, and defensible. ### How to Use This Manual Use this manual when: * starting a new customer engagement * preparing a proposal or Statement of Work * onboarding a team or supplier * planning discovery, alpha, beta, or live delivery * reusing company IP or delivery accelerators * managing risk, change, milestones, and acceptance * preparing evidence for assurance, audit, or customer governance ### Operating Philosophy We operate through a controlled delivery model: * Framework Agreements define the rules of engagement. * Statements of Work define the delivery commitment. * Subcontractor Agreements control delegated work. * Policies and templates enforce consistent execution. * Reusable IP accelerates delivery without weakening governance. * Agile delivery reduces risk through frequent learning, iteration, and evidence-based decisions. ### Core Outcomes Our operating model is designed to produce: * faster mobilisation * clearer scope * stronger commercial control * repeatable delivery quality * reduced delivery risk * controlled IP reuse * better customer confidence * defensible decisions * scalable project delivery # How We Operate ### Overview We operate as a structured delivery organisation. Our model combines commercial discipline, agile delivery, technical assurance, security control, and reusable intellectual property. We do not treat every project as a blank page. We use proven frameworks, templates, accelerators, reference architectures, and delivery playbooks to reduce setup time, improve quality, and increase confidence. ### Our Operating Model Our operating model has five layers: 1. Commercial control 2. Delivery governance 3. Agile execution 4. Technical and security assurance 5. Intellectual property reuse Each layer supports the others. Commercial control ensures that work is properly scoped and authorised. Delivery governance ensures that progress, risk, change, and acceptance are visible. Agile execution ensures that we learn quickly, iterate, and deliver value incrementally. Technical and security assurance ensures that outputs are safe, maintainable, and fit for purpose. IP reuse ensures that proven assets are used to accelerate delivery. ### Non-Negotiables We operate according to the following rules: * No delivery work starts without an agreed commercial basis. * No material scope change proceeds without change control. * No deliverable is accepted without defined acceptance criteria. * No reusable company IP is transferred unless explicitly agreed. * No supplier is engaged without appropriate due diligence and flow-down obligations. * No production release occurs without appropriate quality, security, and approval controls. * No project is managed by assumption where evidence is available. ### What Good Looks Like A well-run engagement has: * a clear Statement of Work * named roles and responsibilities * visible backlog and roadmap * agreed milestones and acceptance criteria * active risk and issue management * regular customer engagement * documented decisions * controlled change * measurable progress * reusable assets applied appropriately # Operating Principles ### Principle 1: Start With the Outcome We define the business, user, operational, and technical outcomes before deciding the solution. ### Principle 2: Work in Controlled Increments We break work into manageable increments with clear objectives, owners, and acceptance criteria. ### Principle 3: Make Work Visible Plans, risks, issues, decisions, dependencies, and progress must be visible to the delivery team and relevant stakeholders. ### Principle 4: Use Evidence Over Opinion We use user research, technical evidence, delivery data, security findings, and customer feedback to guide decisions. ### Principle 5: Reuse Before Rebuild We use existing company IP, patterns, templates, and accelerators where they are suitable. ### Principle 6: Protect the Company Position We protect our commercial position, IP, people, security obligations, and delivery reputation. ### Principle 7: Govern Lightly but Effectively Governance must support delivery, not slow it down. Controls must add value, reduce risk, or improve confidence. ### Principle 8: Design for Assurance We create evidence as we deliver, not retrospectively. Decisions, risks, approvals, and acceptance should be traceable. ### Principle 9: Secure by Default Security, data protection, access control, and auditability are built into delivery from the start. ### Principle 10: Improve Continuously Every project should improve our reusable assets, templates, processes, and delivery knowledge. # Our Delivery Model ### Overview Our delivery model is designed to support complex projects from early discovery through to live operation. It uses agile delivery methods within a controlled commercial and governance framework. ### Delivery Lifecycle We use the following lifecycle: 1. Opportunity qualification 2. Commercial shaping 3. Statement of Work creation 4. Mobilisation 5. Discovery 6. Alpha 7. Beta 8. Live 9. Continuous improvement 10. Retirement or transition ### Delivery Units Work is organised into defined delivery units. A delivery unit may be: * a discovery * a prototype * a product increment * a technical work package * an integration package * a security or assurance package * a support or managed service package Each delivery unit must have: * scope * objectives * deliverables * owner * timeline * dependencies * acceptance criteria * commercial basis ### Delivery Controls Every delivery engagement should maintain: * delivery plan * roadmap * backlog * RAID log * decision log * change log * dependency log * milestone tracker * acceptance record * lessons learned record # Roles, Responsibilities and Accountability ### Overview Clear accountability is essential to controlled delivery. Every project must define who owns outcomes, who makes decisions, who performs delivery activity, and who approves acceptance. ### Core Roles ### Account Director Owns the commercial relationship and customer account strategy. Responsible for: * customer relationship management * commercial positioning * escalation management * account growth * commercial risk visibility ### Delivery Lead Owns delivery execution. Responsible for: * delivery plan * team coordination * milestone tracking * risk and issue management * customer delivery reporting * delivery governance ### Product Lead Owns product direction and prioritisation. Responsible for: * product vision * backlog prioritisation * user needs * roadmap * value definition * outcome measurement ### Technical Lead Owns technical direction. Responsible for: * architecture * technical standards * engineering quality * integration approach * technical risk * technical assurance ### Security Lead Owns security and assurance alignment. Responsible for: * security requirements * risk treatment * access controls * security evidence * audit readiness * secure delivery practices ### Commercial Lead Owns contractual and commercial controls. Responsible for: * Statement of Work alignment * change control * payment milestones * commercial assumptions * supplier commercial flow-down ### Supplier Lead Owns supplier coordination where subcontractors are used. Responsible for: * supplier onboarding * supplier performance * flow-down obligations * supplier risks * supplier deliverables ### RACI Standard Every project should define a RACI for key activities: * Responsible: performs the work * Accountable: owns the outcome * Consulted: contributes expertise * Informed: receives updates # Decision-Making Model ### Overview Decisions must be made at the right level, with the right evidence, at the right time. Delivery teams should be empowered to make decisions within agreed boundaries. ### Decision Categories ### Delivery Decisions Examples: * sprint scope * backlog sequencing * team ways of working * day-to-day prioritisation * issue resolution within agreed tolerance Owner: Delivery Lead or Product Lead ### Technical Decisions Examples: * architecture choices * tooling choices * integration design * data model decisions * deployment approach Owner: Technical Lead ### Security Decisions Examples: * access model * risk treatment * data handling approach * assurance evidence * security acceptance Owner: Security Lead ### Commercial Decisions Examples: * price * payment terms * liability position * IP position * scope changes * subcontract terms Owner: Commercial Lead or Account Director ### Customer Decisions Examples: * acceptance * prioritisation trade-offs * scope approval * milestone approval * change request approval Owner: Customer-appointed decision-maker ### Decision Log Material decisions must be recorded with: * date * decision owner * decision made * options considered * evidence used * impact * follow-up actions # Commercial and Contracting Model ### Overview Our commercial model protects the company while enabling fast, structured delivery. We use clear contractual layers to separate long-term commercial terms from project-specific delivery commitments. ### Contractual Layers ### Layer 1: Framework Agreement The Framework Agreement defines the master rules of engagement. It typically covers: * legal terms * liability * confidentiality * intellectual property * payment framework * governance * ordering process * dispute handling * termination * data protection * security obligations ### Layer 2: Statement of Work The Statement of Work defines the actual work package. It covers: * scope * deliverables * milestones * acceptance criteria * dependencies * assumptions * exclusions * pricing * payment triggers * timeline * governance * customer responsibilities ### Layer 3: Subcontractor Agreement The Subcontractor Agreement is used where we delegate work to a third party. It must align with the customer contract and protect the company from supplier failure. ### Layer 4: Policies and Operating Artifacts Policies and templates enforce consistent delivery. Examples include: * onboarding checklist * change request form * acceptance certificate * milestone report * risk and issue log * security onboarding checklist * repository standards * code review policy ### Commercial Principles We operate commercially according to the following principles: * No work without authority. * No unclear scope. * No unmanaged change. * No untracked acceptance. * No uncontrolled IP leakage. * No supplier delivery without flow-down obligations. * No payment dependency without defined evidence. # Framework Agreements ### Purpose A Framework Agreement provides the master commercial and legal structure for a customer relationship. It allows multiple Statements of Work to be agreed under one consistent contractual framework. ### What the Framework Agreement Controls The Framework Agreement should define: * parties * term * ordering process * Statement of Work mechanism * payment terms * confidentiality * intellectual property * liability * warranties * data protection * security obligations * audit rights * termination * dispute resolution * governance * change control principles ### What the Framework Agreement Does Not Do The Framework Agreement should not normally define detailed delivery scope. Detailed delivery commitments should sit in the Statement of Work. ### Operating Rule A Framework Agreement creates the rules of engagement. A Statement of Work creates the obligation to deliver specific work. # Statements of Work ### Purpose The Statement of Work is the execution unit of delivery. It defines exactly what we are delivering, how delivery will be governed, and how acceptance and payment will work. ### Required Sections Every Statement of Work should include: * title * parties * background * objectives * scope * out of scope * deliverables * milestones * timeline * roles and responsibilities * assumptions * dependencies * customer responsibilities * acceptance criteria * payment schedule * change control process * IP treatment * security requirements * data handling requirements * governance model * reporting cadence * termination consequences * order of precedence ### Scope Standard Scope must be written clearly enough that both parties understand: * what will be delivered * what will not be delivered * what inputs are needed * what assumptions apply * what acceptance means * what happens if requirements change ### Acceptance Standard Each deliverable must have acceptance criteria. Acceptance criteria should be: * objective * testable * linked to the deliverable * time-bound * capable of evidence * agreed before work starts ### Payment Standard Payment triggers should align to clear milestones or deliverables. Payment should not depend on vague or uncontrolled events. # Subcontractor Engagement ### Purpose Subcontractors are used where specialist capability, capacity, or delivery support is required. Subcontractor engagement must be controlled to protect customer delivery, company IP, security obligations, and commercial position. ### Subcontractor Principles * Use subcontractors only where there is a clear business need. * Flow down relevant customer obligations. * Do not expose customer or company information unnecessarily. * Ensure subcontractor deliverables are clearly defined. * Ensure IP ownership and licensing are clear. * Ensure security and confidentiality obligations are enforceable. * Maintain audit and oversight rights. * Track supplier performance throughout delivery. ### Required Controls Before a subcontractor starts work, the following should be in place: * signed subcontractor agreement * agreed scope or work order * NDA or confidentiality terms * security onboarding * access approval * conflict of interest check * insurance evidence where required * right-to-work or compliance checks where applicable * IP assignment or licence terms * delivery and reporting expectations ### Supplier Delivery Risk Supplier risks must be recorded in the project RAID log. Examples include: * dependency on specialist resource * late delivery * unclear acceptance criteria * security clearance delays * customer access constraints * IP contamination * quality issues * insolvency or capacity concerns # Change Control ### Purpose Change control protects delivery, commercial position, timelines, and customer expectations. Any material change to scope, deliverables, milestones, responsibilities, assumptions, pricing, or acceptance criteria must be controlled. ### What Counts as Change A change may include: * new deliverables * removed deliverables * altered acceptance criteria * additional environments * additional integrations * revised timeline * change in customer dependencies * change in security requirements * new reporting requirement * new supplier requirement * expanded support requirement ### Change Request Requirements A change request must include: * change title * change description * reason for change * impact on scope * impact on timeline * impact on cost * impact on risk * impact on IP * impact on security * impact on acceptance * approval status * effective date ### Operating Rule No material change is implemented until approved through the agreed change control process. # Payments, Milestones and Acceptance ### Purpose Milestones and acceptance criteria connect delivery progress to commercial control. They ensure that both parties understand when work is complete and when payment is due. ### Milestone Design A good milestone is: * clearly named * linked to deliverables * time-bound * evidenced * commercially meaningful * capable of acceptance ### Acceptance Criteria Acceptance criteria should define what must be true for a deliverable to be accepted. Examples: * document delivered in agreed format * prototype demonstrates agreed workflow * code merged into agreed repository * test evidence provided * security review completed * customer walkthrough completed * defects resolved to agreed threshold ### Acceptance Process The standard acceptance process is: 1. Deliverable submitted. 2. Evidence provided. 3. Customer review period starts. 4. Customer accepts, rejects with reasons, or requests clarification. 5. Rejection must reference agreed acceptance criteria. 6. Accepted deliverable triggers milestone completion where applicable. ### Payment Evidence Payment evidence may include: * signed acceptance certificate * approved milestone report * customer email approval * delivery dashboard evidence * completed test evidence * repository release tag * deployment record # Agile Delivery Approach ### Overview We follow an agile delivery approach based on user needs, iterative delivery, continuous learning, and evidence-based governance. Agile delivery helps us reduce risk by learning early, delivering in increments, and adapting plans as new information becomes available. ### Our Agile Lifecycle We use the following agile lifecycle: 1. Discovery 2. Alpha 3. Beta 4. Live 5. Retirement or transition ### Why We Use Agile We use agile delivery to: * understand user and customer needs before committing to solutions * test assumptions early * deliver value incrementally * reduce delivery risk * improve transparency * enable faster feedback * support better governance * avoid large late-stage failures ### Agile Within Commercial Control Agile does not mean uncontrolled delivery. We use agile methods within a structured commercial framework. The Statement of Work defines the commercial boundary. The backlog defines the delivery detail. Change control manages material changes. Governance ensures visibility, assurance, and decision-making. # Core Agile Principles ### Principle 1: Focus on User Needs We prioritise user and customer needs over assumptions, internal preferences, or stakeholder opinion. ### Principle 2: Deliver Iteratively We deliver work in increments so that value, risk, and progress can be assessed regularly. ### Principle 3: Improve the Service Continuously We improve the product, service, or deliverable based on research, testing, feedback, and data. ### Principle 4: Improve How the Team Works We use retrospectives and regular team reflection to improve collaboration, quality, and pace. ### Principle 5: Fail Fast and Learn Quickly We test risky assumptions early so that weak ideas can be stopped before they become expensive. ### Principle 6: Keep Planning Planning is continuous. We maintain a vision, objectives, roadmap, and backlog, and we update them as we learn. ### Principle 7: Make Progress Visible The team should be able to show: * what has been done * what is in progress * what is blocked * what is next * what risks exist * what decisions are needed ### Principle 8: Build Quality In Quality is not inspected only at the end. It is built into requirements, design, engineering, review, testing, security, and acceptance. # Discovery ### Purpose Discovery is used to understand the problem before committing to a solution. The goal is to learn enough to decide whether to proceed, stop, reshape, or move into alpha. ### Key Questions Discovery should answer: * Who are the users? * What are they trying to achieve? * What problem are we solving? * What constraints exist? * What policy, legal, security, technical, or operational factors apply? * What has already been tried? * What data or evidence exists? * What risks are most important? * What options should be explored in alpha? ### Discovery Activities Typical discovery activities include: * stakeholder interviews * user research * process mapping * current-state analysis * technical discovery * data discovery * security discovery * supplier and dependency mapping * risk assessment * opportunity assessment * high-level roadmap creation ### Discovery Outputs Discovery should produce: * problem statement * user needs summary * stakeholder map * current-state assessment * constraints log * risks and assumptions log * options assessment * alpha recommendation * initial roadmap * commercial recommendation ### Exit Criteria Discovery is complete when: * the problem is clearly understood * key user needs are identified * constraints and risks are visible * there is enough evidence to decide whether to proceed * alpha objectives are defined if proceeding # Alpha ### Purpose Alpha is used to test possible solutions and the riskiest assumptions. The goal is to learn which approach is most likely to work before building at scale. ### Alpha Principles During alpha, we: * test ideas quickly * prototype only what is necessary * focus on risky assumptions * avoid premature production build * challenge existing ways of working * learn from users and stakeholders * decide what should move into beta ### Alpha Activities Typical alpha activities include: * prototype design * technical feasibility testing * user journey testing * architecture options * integration experiments * security risk exploration * data-sharing feasibility * operational impact assessment * commercial model refinement ### Alpha Outputs Alpha should produce: * tested prototype or prototypes * evidence of user feedback * technical feasibility assessment * preferred solution option * delivery risks * beta backlog * beta roadmap * updated commercial assumptions * recommendation to proceed, stop, or reshape ### Exit Criteria Alpha is complete when: * key assumptions have been tested * the preferred solution is justified by evidence * major risks are visible * beta scope is defined * beta delivery approach is credible # Beta ### Purpose Beta is where the best idea from alpha is built for real users. The goal is to develop, test, improve, and prepare the service or product for live operation. ### Private Beta Private beta is used with a limited group of users. It allows the team to: * validate the service with real users * identify usability issues * test operational support * refine technical performance * improve security and reliability * reduce risk before wider release ### Public Beta Public beta is used when the service is ready for wider use but still being actively improved. It allows the team to: * test scale * monitor performance * gather broader feedback * improve support processes * prepare for live transition ### Beta Activities Typical beta activities include: * product build * user research * accessibility testing * security testing * performance testing * integration testing * operational readiness planning * service support design * data protection review * release planning ### Beta Outputs Beta should produce: * working service or product * tested user journeys * service metrics * support model * technical documentation * security evidence * release plan * live readiness assessment * updated roadmap ### Exit Criteria Beta is complete when: * the service works for users * operational support is ready * security and assurance requirements are met * performance is acceptable * metrics are in place * the service is ready to move into live operation # Live ### Purpose Live is the sustainable operation and continuous improvement phase. The goal is to run the service safely, monitor performance, and keep improving based on evidence. ### Live Activities Typical live activities include: * service monitoring * incident management * user support * performance analysis * security monitoring * vulnerability management * continuous improvement * roadmap management * release management * operational reporting ### Live Standards A live service should have: * named service ownership * support model * uptime and availability approach * incident process * monitoring and alerting * security controls * accessibility compliance * performance metrics * change and release controls * roadmap for improvement ### Continuous Improvement During live, improvements should be based on: * user research * service analytics * operational feedback * support data * security findings * customer priorities * technical debt assessment ### Exit Criteria Live continues until the service is transitioned, replaced, or retired. # Retirement ### Purpose Retirement is used when a service, product, component, or process is no longer needed, no longer cost-effective, or is being replaced. ### Retirement Triggers Retirement may be considered when: * users no longer need the service * usage is too low to justify ongoing cost * a better service has replaced it * technology is obsolete * security risk is unacceptable * contractual support has ended * customer strategy has changed ### Retirement Activities Typical retirement activities include: * user impact assessment * customer approval * data retention review * migration planning * communication plan * archive plan * access removal * supplier exit * decommissioning * final reporting ### Retirement Outputs Retirement should produce: * retirement decision record * impact assessment * migration or transition plan * data handling record * decommissioning evidence * final acceptance or closure record # Agile Ceremonies ### Overview Agile ceremonies create rhythm, visibility, and learning. They should be lightweight, purposeful, and focused on progress. ### Daily Stand-Up Purpose: * align the team * identify blockers * coordinate work * maintain delivery pace Standard questions: * What did we complete? * What are we working on next? * What is blocked? * What decisions are needed? ### Sprint Planning Purpose: * agree sprint objectives * select work from the backlog * confirm dependencies * identify risks * align team capacity ### Backlog Refinement Purpose: * clarify upcoming work * break down large items * define acceptance criteria * estimate effort * identify dependencies ### Show and Tell Purpose: * demonstrate progress * gather feedback * improve transparency * support decision-making ### Retrospective Purpose: * inspect how the team is working * identify improvements * agree actions * track whether improvements worked ### Governance Review Purpose: * review progress * review risks and issues * confirm decisions * review milestones * manage escalations * maintain customer confidence # Backlog, Roadmap and Prioritisation ### Overview The roadmap explains where we are going. The backlog explains what we are doing next. Prioritisation ensures that effort is focused on the highest-value work. ### Roadmap The roadmap should show: * vision * objectives * major phases * key milestones * dependencies * releases * decision points * risks * expected value ### Backlog The backlog should contain: * user stories * technical tasks * research tasks * security tasks * defect fixes * operational tasks * documentation tasks * assurance tasks ### Prioritisation Criteria Work should be prioritised using: * user value * customer value * risk reduction * dependency impact * security need * commercial importance * delivery effort * urgency * regulatory or contractual requirement ### Definition of Ready A backlog item is ready when: * the objective is clear * acceptance criteria are defined * dependencies are understood * required inputs are available * the team understands the work * the item can be delivered within the planned period ### Definition of Done A backlog item is done when: * acceptance criteria are met * quality checks are complete * security requirements are satisfied * documentation is updated * evidence is recorded * review or approval is complete where required # Delivery Governance ### Purpose Governance ensures that delivery remains controlled, visible, and aligned to customer and company objectives. Governance must support delivery rather than create unnecessary friction. ### Governance Principles We use governance to: * make decisions at the right level * keep delivery moving * manage risk and issues * protect commercial position * assure quality * maintain customer confidence * create evidence * support escalation when needed ### Governance Cadence A typical governance cadence includes: * daily team stand-up * weekly delivery review * weekly customer checkpoint * fortnightly show and tell * monthly steering review * milestone acceptance review * retrospective at the end of each iteration ### Governance Artifacts Each engagement should maintain: * delivery plan * roadmap * backlog * RAID log * change log * decision log * dependency log * milestone tracker * acceptance register * commercial tracker # Delivery Assurance ### Purpose Delivery assurance gives confidence that work is progressing, risks are managed, and outputs are fit for purpose. ### Assurance Areas Delivery assurance covers: * scope * schedule * cost * quality * security * technical architecture * commercial obligations * supplier delivery * acceptance evidence * customer readiness ### Assurance Questions A delivery review should ask: * Are we delivering the agreed scope? * Are milestones on track? * Are risks and issues visible? * Are blockers being resolved? * Are decisions being made at the right level? * Is the customer fulfilling dependencies? * Is quality being built in? * Are security obligations being met? * Is acceptance evidence being captured? * Are changes being controlled? ### Assurance Evidence Evidence may include: * signed Statement of Work * approved delivery plan * sprint reports * backlog reports * test evidence * architecture decisions * security review records * code review records * acceptance certificates * customer approvals # Risk and Issue Management ### Purpose Risk and issue management ensures that threats to delivery are visible, owned, and actively managed. ### Risk A risk is something that may happen and may affect delivery. Risk records should include: * description * cause * impact * probability * severity * owner * mitigation * contingency * status * review date ### Issue An issue is something that has happened and is affecting delivery. Issue records should include: * description * impact * owner * priority * action plan * due date * escalation route * status ### Escalation Escalate when: * a risk exceeds tolerance * an issue blocks delivery * a customer dependency is not met * a commercial decision is needed * security approval is delayed * supplier failure threatens delivery * acceptance is disputed ### Operating Rule Risks and issues must be reviewed regularly and not left as static records. # Reporting and Progress Tracking ### Purpose Reporting must support decision-making without creating unnecessary overhead. Good reporting shows progress, risk, blockers, decisions, and next steps. ### Weekly Delivery Report The weekly delivery report should include: * overall status * progress this period * planned work next period * milestone status * risks * issues * dependencies * decisions required * change requests * commercial or acceptance matters * support required from customer ### Status Definitions ### Green Delivery is on track. No material intervention required. ### Amber Delivery is at risk. Management action or customer decision may be required. ### Red Delivery is materially off track. Immediate escalation required. ### Progress Measures Use a balanced view of progress: * completed deliverables * accepted milestones * backlog movement * user research findings * technical progress * risk reduction * test evidence * defect trends * readiness indicators # Project Controls ### Purpose Project controls ensure that delivery is planned, tracked, and governed. ### Required Controls Each project should maintain: * approved Statement of Work * delivery plan * project initiation document * governance cadence * RAID log * change log * decision log * dependency log * milestone tracker * acceptance register * financial tracker * resourcing plan ### Control Reviews Controls should be reviewed: * at mobilisation * before each milestone * during weekly delivery reviews * before customer governance meetings * when a major risk or change occurs * before acceptance * at closure ### Control Ownership The Delivery Lead owns project controls. The Commercial Lead owns commercial controls. The Technical Lead owns technical controls. The Security Lead owns security controls. # Acceptance and Sign-Off ### Purpose Acceptance confirms that a deliverable has met agreed criteria. Acceptance must be evidence-based and commercially traceable. ### Acceptance Inputs Acceptance should be based on: * agreed deliverable definition * agreed acceptance criteria * submitted evidence * customer review * defect or exception status * approval record ### Acceptance Outcomes Possible outcomes: * accepted * accepted with minor observations * rejected with reasons * deferred pending customer dependency * withdrawn due to change control ### Rejection Standard A rejection must: * identify the failed acceptance criterion * explain the issue * provide evidence * define required remediation * confirm review timescale ### Acceptance Record Acceptance records should include: * deliverable name * version * submission date * acceptance criteria * evidence provided * review outcome * approver * approval date * comments # Intellectual Property and Accelerators ### Purpose Our intellectual property strategy allows us to deliver faster while protecting the company’s long-term value. We use reusable IP to accelerate projects, reduce cost, improve quality, and avoid rebuilding common assets. ### IP Categories We classify IP into the following categories: * Background IP * Foreground IP * Customer IP * Third-party IP * Open-source components * Reusable delivery accelerators * Project-specific know-how ### IP Principles * We protect our Background IP. * We define Foreground IP treatment in the contract or Statement of Work. * We do not transfer reusable company assets unless explicitly agreed. * We avoid accidental IP leakage. * We maintain records of reusable assets. * We respect customer confidentiality and customer-owned materials. * We assess third-party and open-source components before use. * We improve reusable IP after each engagement where appropriate. ### How IP Speeds Up Projects Reusable IP allows us to start faster and deliver with more confidence. Examples include: * reference architectures * delivery playbooks * Statement of Work templates * discovery question sets * security control packs * engineering templates * reusable components * integration patterns * test scripts * data models * governance templates * acceptance criteria libraries * project mobilisation checklists ### Operating Rule Reusable IP may be used to accelerate delivery, but its ownership, licensing, and permitted use must remain controlled. # Background IP ### Definition Background IP is intellectual property that existed before a project or was developed independently of a customer engagement. Our IP is defined by the `AIC.*` namespace ### Examples Background IP may include: * templates * frameworks * accelerators * software libraries * reusable code * architecture patterns * delivery methods * policies * playbooks * know-how * tooling * checklists * training materials ### Ownership Background IP remains owned by the company unless expressly agreed otherwise in writing. ### Customer Use Where needed, a customer may receive a limited licence to use Background IP as part of the delivered solution. The licence should be defined in the Framework Agreement or Statement of Work. ### Protection Rules * Do not copy reusable IP into customer-owned repositories unless approved. * Do not mark company reusable IP as customer-owned. * Do not include Background IP in deliverables without checking the IP position. * Do not transfer ownership of Background IP by implication. * Keep reusable assets in controlled repositories. # Foreground IP ### Definition Foreground IP is intellectual property created specifically during a project. ### Treatment Foreground IP treatment must be defined in the relevant contract or Statement of Work. Possible models include: * customer owns Foreground IP * company owns Foreground IP and grants customer a licence * shared ownership * ownership split by deliverable type * company retains reusable components and customer receives project-specific outputs ### Key Considerations Before agreeing Foreground IP terms, consider: * whether reusable company IP is embedded * whether third-party IP is included * whether customer data or confidential information is involved * whether the output has future reuse value * whether the customer requires ownership for operational reasons * whether licensing is sufficient * whether supplier IP is involved ### Operating Rule Never assume Foreground IP ownership. Always check the contract and Statement of Work. # Reusable Assets and Accelerators ### Purpose Reusable assets help us deliver faster, reduce risk, and improve consistency. They allow teams to build on proven work rather than starting from nothing. ### Types of Accelerators ### Commercial Accelerators * proposal templates * pricing models * Statement of Work templates * change control templates * acceptance certificate templates * commercial risk checklists ### Delivery Accelerators * mobilisation checklist * project initiation templates * delivery plan templates * agile ceremony packs * RAID log templates * reporting templates * roadmap templates ### Technical Accelerators * reference architectures * reusable components * integration patterns * infrastructure templates * deployment pipelines * code scaffolds * API standards * test harnesses ### Security Accelerators * security onboarding checklist * data classification templates * access control matrix * threat modelling templates * secure development checklist * security evidence packs ### Assurance Accelerators * quality gate templates * acceptance criteria libraries * test evidence templates * architecture decision record templates * service readiness checklist ### Reuse Criteria An asset may be reused where it is: * relevant * current * approved * secure * legally usable * technically appropriate * free from customer confidential material unless permitted * compatible with the project IP position # Asset Library ### Purpose The asset library is the controlled home for reusable company materials. ### Asset Categories The asset library should contain: * commercial templates * delivery templates * engineering standards * architecture patterns * security control packs * code components * deployment assets * testing assets * governance artefacts * lessons learned ### Asset Record Each reusable asset should have: * name * description * owner * version * status * approved use * licence or IP notes * dependencies * security classification * last reviewed date * repository location * usage notes ### Asset Status ### Draft Asset is under development and not yet approved for general reuse. ### Approved Asset is approved for reuse. ### Restricted Asset may be reused only with approval. ### Deprecated Asset should not be used for new work. ### Retired Asset is no longer available for use. ### Review Cycle Assets should be reviewed: * after major project use * after customer feedback * after security findings * after legal or commercial changes * at scheduled review intervals # IP Reuse Rules ### Rule 1: Check the Contract Before reusing or delivering IP, check the applicable Framework Agreement, Statement of Work, subcontract, and customer obligations. ### Rule 2: Identify the IP Category Classify the asset as: * Background IP * Foreground IP * customer IP * supplier IP * third-party IP * open-source component ### Rule 3: Confirm Permitted Use Confirm that the asset can be used in the project. Check: * ownership * licence * confidentiality * security classification * customer restrictions * third-party restrictions ### Rule 4: Keep Reusable Assets Separate Where possible, keep reusable company assets separate from customer-specific deliverables. ### Rule 5: Avoid Customer Confidential Contamination Do not add customer confidential information into reusable company assets unless the asset is clearly restricted and legally approved. ### Rule 6: Record Improvements If a project improves a reusable asset, record: * what changed * who made the change * whether the improvement is reusable * whether customer restrictions apply * whether approval is needed before reuse ### Rule 7: Do Not Over-Promise Do not promise transfer of reusable assets unless approved commercially and legally. # Open Source and Third-Party Components ### Purpose Open-source and third-party components can accelerate delivery but must be managed carefully. ### Required Checks Before use, check: * licence type * commercial restrictions * attribution requirements * security vulnerabilities * maintenance status * compatibility with customer requirements * export or regulatory restrictions * support model * IP contamination risk ### Approved Use A component may be used where: * the licence is acceptable * security risk is acceptable * the component is actively maintained or risk-managed * the customer permits its use * the component does not conflict with the project IP model ### Records Projects should record: * component name * version * licence * source * purpose * approval status * known vulnerabilities * mitigation # Engineering and Technical Standards ### Overview Engineering work must be secure, maintainable, testable, and aligned to the agreed architecture. ### Principles * Build for the user need. * Keep designs simple where possible. * Prefer reusable patterns. * Automate repeatable tasks. * Make systems observable. * Document important decisions. * Build security in from the start. * Test early and continuously. * Review code before release. * Manage technical debt deliberately. ### Engineering Evidence Engineering teams should maintain: * architecture decision records * repository documentation * code review evidence * test evidence * deployment records * release notes * security review evidence # Architecture Standards ### Purpose Architecture standards ensure that solutions are coherent, secure, maintainable, and aligned to customer requirements. ### Architecture Artifacts Projects should maintain: * context diagram * logical architecture * physical architecture where required * integration model * data model * security architecture * deployment architecture * architecture decision records ### Architecture Decisions Material architecture decisions must record: * decision * context * options considered * rationale * consequences * risks * owner * date ### Architecture Review Architecture should be reviewed: * during discovery * during alpha * before beta build * before live release * after major change requests # Secure Development ### Purpose Secure development ensures that security is built into delivery rather than added at the end. ### Secure Development Practices Teams should use: * secure coding practices * code review * dependency scanning * secrets management * least privilege access * secure configuration * logging and monitoring * vulnerability management * threat modelling where appropriate * security testing before release ### Security Evidence Projects should retain: * security requirements * threat model * access control record * vulnerability scan results * penetration test results where applicable * remediation records * risk acceptance records # Repository and Version Control Standards ### Purpose Repository standards ensure that code, configuration, documentation, and evidence are controlled. ### Repository Requirements Repositories should include: * README * contribution guidance * branching strategy * code owners where appropriate * licence or IP notice * setup instructions * test instructions * deployment instructions * security notes * changelog ### Branching Branching strategy must be defined for the project. Typical branches include: * main * develop * feature branches * release branches * hotfix branches ### Commit Standards Commits should be: * clear * traceable * linked to work items where possible * focused on a single logical change ### Release Tags Releases should be tagged and documented. # Code Review and Quality Gates ### Purpose Code review and quality gates reduce defects, improve maintainability, and support assurance. ### Code Review Criteria Reviewers should check: * correctness * readability * maintainability * security * test coverage * performance implications * dependency changes * architectural fit * documentation updates ### Quality Gates Quality gates may include: * peer review completed * automated tests passed * security scan completed * dependency check completed * accessibility check completed where applicable * deployment test completed * release approval recorded ### Operating Rule No material code should be released without appropriate review and evidence. # Release and Deployment Standards ### Purpose Release and deployment standards ensure that changes are controlled, tested, and recoverable. ### Release Requirements A release should have: * release owner * release scope * version number * release notes * test evidence * deployment plan * rollback plan * approval record * known issues * support contact ### Deployment Controls Deployment should include: * environment confirmation * access confirmation * backup or rollback approach * monitoring plan * post-deployment validation * incident route ### Release Evidence Retain: * release notes * deployment logs * approval record * test results * validation evidence # Security, Compliance and Data ### Purpose Security is part of delivery from the start. The security operating model ensures that people, systems, data, suppliers, and customer environments are protected. ### Security Principles * Apply least privilege. * Classify information before sharing. * Use approved tools and repositories. * Keep access traceable. * Record security decisions. * Review supplier access. * Manage vulnerabilities. * Treat customer data with appropriate care. * Escalate incidents quickly. ### Security Responsibilities Security responsibilities should be defined for: * delivery team * technical lead * security lead * customer security contact * supplier security contact * system owner * data owner # Data Handling and Classification ### Purpose Data handling rules protect customer information, company information, personal data, and sensitive material. ### Data Classification Projects should classify data as: * public * internal * confidential * sensitive * customer confidential * personal data * special category personal data where applicable ### Government Classifications When work is conduct on HMG projects or HMG aligned projects, we classify our data following GOV.UK guidelines. * OFFICIAL * OFFICIAL-SENSITIVE * SECRET * TOP SECRET ### Data Handling Rules Data must be: * stored only in approved locations * accessed only by authorised users * shared only through approved channels * retained only for the required period * deleted or returned when required * encrypted where appropriate * handled according to customer requirements ### Data Register Projects handling sensitive or customer data should maintain a data register showing: * data type * source * owner * storage location * access permissions * retention period * deletion process # Access Control ### Purpose Access control ensures that only authorised people can access systems, repositories, data, and environments. ### Access Principles * least privilege * role-based access * named user accounts * no shared credentials * timely removal of access * periodic access review * multi-factor authentication where required ### Access Request Access requests should record: * requester * role * system * reason * approval * access level * start date * end date * review date ### Offboarding Access must be removed when: * a person leaves the project * a supplier engagement ends * a role changes * the customer requests removal * access is no longer needed # Audit and Evidence ### Purpose Audit evidence allows the company to demonstrate that delivery was controlled, secure, and compliant. ### Evidence Types Evidence may include: * contracts * Statements of Work * approvals * meeting records * decision logs * change records * risk logs * test evidence * security records * acceptance records * access records * release records ### Evidence Standards Evidence should be: * dated * attributable * complete * stored in an approved location * linked to the relevant deliverable or control * retained according to the applicable requirement # Information Assurance ### Purpose Information assurance ensures that information risks are understood and managed. ### Assurance Areas Information assurance covers: * confidentiality * integrity * availability * data protection * access control * auditability * resilience * supplier assurance * incident response ### Assurance Activities Projects may require: * security requirements review * data protection review * threat modelling * vulnerability scanning * penetration testing * supplier security review * operational readiness review * risk acceptance # Supplier Security Requirements ### Purpose Suppliers must meet security requirements appropriate to the work they perform. ### Supplier Security Controls Suppliers may be required to provide: * security policy evidence * personnel checks * confidentiality commitments * access control compliance * secure development practices * incident notification process * insurance evidence * data handling compliance * audit cooperation ### Supplier Access Supplier access should be: * approved * limited * monitored * time-bound * removed promptly when no longer required # People, Suppliers and Onboarding ### Overview Teams are formed around outcomes. A delivery team should include the skills needed to understand the problem, deliver the solution, manage risk, and support the customer. ### Typical Team Composition A project team may include: * Account Director * Delivery Lead * Product Lead * Technical Lead * Security Lead * Business Analyst * User Researcher * Service Designer * Engineer * Tester * DevOps Engineer * Commercial Lead * Supplier Lead ### Team Principles * clear accountability * visible work * regular communication * shared standards * fast escalation * evidence-based decisions * continuous improvement # Internal Onboarding ### Purpose Internal onboarding ensures that team members understand the project, customer, controls, tools, and expectations. ### Onboarding Checklist Each team member should receive: * project overview * Statement of Work summary * role description * delivery plan * governance cadence * access instructions * security briefing * data handling requirements * repository access * communication channels * risk and issue process * escalation routes * IP rules # Supplier Onboarding ### Purpose Supplier onboarding ensures that third parties can contribute safely and effectively. ### Supplier Onboarding Checklist Before work starts: * contract signed * scope agreed * NDA or confidentiality terms confirmed * insurance checked where required * security requirements issued * access approved * conflict check completed * delivery expectations agreed * reporting cadence agreed * IP position confirmed * customer restrictions understood ### Supplier Performance Supplier performance should be reviewed against: * delivery quality * timeliness * responsiveness * security compliance * documentation quality * acceptance performance * collaboration # Ways of Working ### Overview Ways of working define how teams collaborate day to day. ### Standards Teams should agree: * working hours * communication channels * meeting cadence * escalation process * documentation location * repository location * decision logging process * risk and issue process * customer communication rules ### Communication Principles Communication should be: * clear * timely * factual * action-oriented * recorded where material # Performance Expectations ### Overview Performance expectations ensure that everyone understands the standard required. ### Expectations Team members and suppliers are expected to: * deliver agreed work * communicate blockers early * follow security requirements * maintain professional standards * document decisions * contribute to improvement * protect company and customer information * use approved tools * escalate risks appropriately # Templates and Operating Artifacts ### Overview Templates standardise delivery and reduce setup time. ### Commercial Templates * Framework Agreement checklist * Statement of Work template * Change request template * Acceptance certificate * Pricing schedule * Invoice requirements guide * Expense policy ### Delivery Templates * Project initiation document * Weekly report * Milestone report * RAID log * Decision log * Dependency log * Roadmap * Backlog structure ### Technical Templates * Architecture decision record * Repository README * Release notes * Test evidence record * Deployment plan * Rollback plan ### Security Templates * Security onboarding checklist * Data classification record * Access control matrix * Threat model * Vulnerability remediation log # Statement of Work Template ### 1. Title \[Project / Work Package Name] ### 2. Parties Customer: \[Customer Name] Supplier: \[Company Name] ### 3. Background \[Brief context for the work.] ### 4. Objectives The objectives of this Statement of Work are: * \[Objective 1] * \[Objective 2] * \[Objective 3] ### 5. Scope The scope includes: * \[Scope item 1] * \[Scope item 2] * \[Scope item 3] ### 6. Out of Scope The following are excluded: * \[Exclusion 1] * \[Exclusion 2] * \[Exclusion 3] ### 7. Deliverables | Deliverable | Description | Acceptance Criteria | Due Date | | ---------------- | -------------- | ------------------- | -------- | | \[Deliverable 1] | \[Description] | \[Criteria] | \[Date] | ### 8. Milestones | Milestone | Deliverables | Payment Trigger | Target Date | | -------------- | --------------- | --------------- | ----------- | | \[Milestone 1] | \[Deliverables] | \[Trigger] | \[Date] | ### 9. Assumptions * \[Assumption 1] * \[Assumption 2] ### 10. Dependencies * \[Dependency 1] * \[Dependency 2] ### 11. Customer Responsibilities * \[Responsibility 1] * \[Responsibility 2] ### 12. Governance Governance will include: * weekly delivery review * milestone review * risk and issue review * change control review ### 13. Change Control Any material change must be agreed through the change control process. ### 14. Intellectual Property IP treatment is as follows: * Background IP: \[position] * Foreground IP: \[position] * Customer IP: \[position] * Third-party IP: \[position] ### 15. Security and Data Security and data requirements: * \[Requirement 1] * \[Requirement 2] ### 16. Acceptance Acceptance will be managed against the criteria defined in this Statement of Work. ### 17. Payment | Payment Milestone | Amount | Trigger | | ----------------- | --------: | ---------- | | \[Milestone] | \[Amount] | \[Trigger] | ### 18. Sign-Off Customer authorised signatory: Name: Role: Date: Supplier authorised signatory: Name: Role: Date: # Project Initiation Document Template ### Project Name \[Project Name] ### Customer \[Customer Name] ### Project Summary \[Short summary.] ### Objectives * \[Objective 1] * \[Objective 2] ### Scope \[Scope summary.] ### Out of Scope \[Out of scope summary.] ### Delivery Approach \[Discovery / Alpha / Beta / Live / Other] ### Team | Role | Name | Responsibility | | ------------- | ------- | ----------------- | | Delivery Lead | \[Name] | \[Responsibility] | ### Governance | Meeting | Frequency | Attendees | Purpose | | --------------- | --------- | ------------ | --------------- | | Delivery Review | Weekly | \[Attendees] | Review progress | ### Milestones | Milestone | Date | Owner | | ------------ | ------- | -------- | | \[Milestone] | \[Date] | \[Owner] | ### Risks | Risk | Impact | Owner | Mitigation | | ------- | --------- | -------- | ------------- | | \[Risk] | \[Impact] | \[Owner] | \[Mitigation] | ### Dependencies | Dependency | Owner | Required By | | ------------- | -------- | ----------- | | \[Dependency] | \[Owner] | \[Date] | ### Acceptance \[Acceptance approach.] ### Security \[Security requirements.] ### IP \[IP position.] ### Approval Approved by: Date: # Weekly Report Template ### Reporting Period \[Date range] ### Overall Status Status: Green / Amber / Red ### Executive Summary \[Short summary.] ### Progress This Period * \[Progress item 1] * \[Progress item 2] ### Planned Work Next Period * \[Planned item 1] * \[Planned item 2] ### Milestone Status | Milestone | Status | Date | Notes | | ------------ | --------- | ------- | -------- | | \[Milestone] | \[Status] | \[Date] | \[Notes] | ### Risks | Risk | Rating | Owner | Action | | ------- | --------- | -------- | --------- | | \[Risk] | \[Rating] | \[Owner] | \[Action] | ### Issues | Issue | Impact | Owner | Action | | -------- | --------- | -------- | --------- | | \[Issue] | \[Impact] | \[Owner] | \[Action] | ### Decisions Required | Decision | Owner | Required By | | ----------- | -------- | ----------- | | \[Decision] | \[Owner] | \[Date] | ### Changes | Change | Status | Impact | | --------- | --------- | --------- | | \[Change] | \[Status] | \[Impact] | ### Support Required \[Customer or internal support required.] # Milestone Report Template ### Milestone Name \[Milestone Name] ### Reporting Date \[Date] ### Summary \[Milestone summary.] ### Deliverables Submitted | Deliverable | Version | Evidence | Status | | -------------- | ---------- | ----------- | --------- | | \[Deliverable] | \[Version] | \[Evidence] | \[Status] | ### Acceptance Criteria | Criterion | Evidence | Met | | ------------ | ----------- | -------- | | \[Criterion] | \[Evidence] | Yes / No | ### Risks and Issues \[Summary of any risks or issues.] ### Dependencies \[Summary of dependencies.] ### Recommendation Accept / Reject / Accept with observations ### Approval Customer approver: Date: Supplier approver: Date: # Change Request Template ### Change Request ID \[CR-000] ### Title \[Change title] ### Requested By \[Name] ### Date \[Date] ### Description \[Describe the requested change.] ### Reason \[Why the change is needed.] ### Impact Assessment ### Scope Impact \[Impact.] ### Timeline Impact \[Impact.] ### Cost Impact \[Impact.] ### Security Impact \[Impact.] ### IP Impact \[Impact.] ### Risk Impact \[Impact.] ### Acceptance Impact \[Impact.] ### Recommendation Approve / Reject / Defer ### Approval Customer approver: Supplier approver: Effective date: # Acceptance Certificate Template ### Deliverable \[Deliverable name] ### Statement of Work \[SoW reference] ### Version \[Version] ### Submission Date \[Date] ### Acceptance Criteria | Criterion | Evidence | Result | | ------------ | ----------- | ----------- | | \[Criterion] | \[Evidence] | Pass / Fail | ### Acceptance Decision Accepted / Rejected / Accepted with observations ### Comments \[Comments.] ### Customer Approval Name: Role: Signature: Date: ### Supplier Confirmation Name: Role: Signature: Date: # Risk and Issue Log Template ### Risk Log | ID | Risk | Probability | Impact | Rating | Owner | Mitigation | Status | | ----- | ------- | --------------: | --------------: | --------: | -------- | ------------- | --------- | | R-001 | \[Risk] | \[Low/Med/High] | \[Low/Med/High] | \[Rating] | \[Owner] | \[Mitigation] | \[Status] | ### Issue Log | ID | Issue | Impact | Priority | Owner | Action | Due Date | Status | | ----- | -------- | --------- | ----------- | -------- | --------- | -------- | --------- | | I-001 | \[Issue] | \[Impact] | \[Priority] | \[Owner] | \[Action] | \[Date] | \[Status] | # Glossary ### Acceptance Criteria The agreed conditions that must be met for a deliverable to be accepted. ### Agile An iterative approach to delivery based on learning, feedback, prioritisation, and incremental progress. ### Alpha The phase used to test possible solutions and risky assumptions. ### Background IP Intellectual property that existed before a project or was developed independently of the customer engagement. ### Backlog The prioritised list of work items to be delivered by the team. ### Beta The phase where the chosen solution is built and tested with real users. ### Change Control The process for assessing and approving changes to scope, time, cost, risk, acceptance, or obligations. ### Delivery Governance The system of meetings, controls, evidence, and decisions used to keep delivery on track. ### Discovery The phase used to understand the problem, users, constraints, and options before committing to a solution. ### Foreground IP Intellectual property created specifically during a project. ### Framework Agreement The master agreement that defines the overall commercial and legal relationship. ### Live The phase where the service is operated, monitored, supported, and continuously improved. ### RAID Risks, Assumptions, Issues, and Dependencies. ### Roadmap A plan showing how a product, service, or project is expected to develop over time. ### Statement of Work The contractual document that defines the specific work package, deliverables, milestones, acceptance criteria, and payment triggers. ### Subcontractor A third party engaged to perform part of the work on behalf of the company. # Agile Delivery Playbook ### Purpose This GitBook explains how we deliver work using an agile approach. It is separate from the company operating manual. The operating manual explains how the company is structured, governed and commercially controlled. This playbook explains how delivery teams actually run work from early discovery through to live service operation and eventual retirement. This playbook is designed for customers, internal teams, delivery partners and subcontractors. It gives people a detailed view of how we plan, research, build, test, assure, release and improve services. ### Source Basis This playbook is adapted from the GOV.UK Service Manual guidance on agile delivery, including the sections on agile principles, agile methods, planning, roadmaps, governance, measuring progress, discovery, alpha, beta, live and retiring services. GOV.UK source: ### How This Playbook Is Tailored The GOV.UK material explains good practice for agile public service delivery. This playbook translates those practices into our delivery model. Our model adds the controls needed for professional services, enterprise delivery, high-assurance environments and statement-of-work-led engagements. Our agile delivery model is therefore: * user-centred * iterative * evidence-led * commercially controlled * security-aware * IP-conscious * supplier-ready * assurance-friendly * suitable for complex customer environments ### Our Delivery Lifecycle We use five delivery phases: 1. Discovery 2. Alpha 3. Beta 4. Live 5. Retirement Not every engagement uses every phase in full. The phase model is a decision framework. It helps us understand what evidence is needed, what work should happen next and what level of commitment is appropriate. ### How Agile Fits With Commercial Control Agile delivery does not remove commercial discipline. The Statement of Work defines the authorised commercial boundary. The backlog defines the delivery detail inside that boundary. Governance reviews make progress visible. Change control manages material change. Acceptance criteria define completion. IP controls ensure reusable assets are protected and customer-specific outputs are handled correctly. ### What Good Looks Like A well-run agile engagement has: * a clear problem statement * visible user needs * agreed outcomes * a prioritised backlog * a roadmap that evolves as we learn * regular delivery rhythm * clear governance cadence * active risk and issue management * evidence-based decisions * strong technical and security assurance * measurable progress * clear acceptance criteria * controlled use of reusable IP * documented learning and improvement ### How to Use This GitBook Use this playbook when: * explaining our agile approach to a customer * preparing a proposal or Statement of Work * planning a discovery, alpha, beta or live phase * onboarding a delivery team * onboarding a subcontractor * setting up governance * defining acceptance criteria * deciding whether to proceed to the next phase * reviewing delivery health * preparing assurance evidence # Source Basis and Licence ### Primary Source This playbook is based on the GOV.UK Service Manual agile delivery guidance: The GOV.UK guidance covers agile principles, agile methods, tools and techniques, user stories, planning, prioritisation, roadmaps, governance, measuring progress, spending controls, running and improving services, discovery, alpha, beta, live and retiring services. ### Licence Position GOV.UK states that its content is available under the Open Government Licence v3.0, except where otherwise stated. Open Government Licence v3.0: ### Adaptation Statement This GitBook is not a copy of the GOV.UK Service Manual. It is a tailored operating guide that adapts the GOV.UK agile delivery approach for our professional services model. The tailoring adds: * Statement of Work alignment * commercial governance * milestone and acceptance controls * reusable IP and accelerator controls * supplier and subcontractor alignment * security and data assurance * delivery evidence standards * practical checklists and templates ### How to Reference This Internally When presenting this process to customers or partners, describe it as: > Our agile delivery process is aligned to the GOV.UK Service Manual agile delivery guidance and tailored for statement-of-work-led professional services, controlled IP reuse, enterprise governance and high-assurance delivery. ### Important Boundary This playbook explains our delivery process. It does not replace the contract, Framework Agreement, Statement of Work, data processing terms, security schedule or any other legally binding document. Where there is conflict, the signed contractual documents take precedence. # Foundations ### Overview We use agile delivery to reduce uncertainty, increase transparency and deliver useful outcomes earlier. Agile is not a lack of structure. It is a disciplined way of learning, prioritising and delivering in controlled increments. Our agile model is designed for real customer environments where delivery must satisfy multiple needs at once: * users need services that work * customers need confidence and visibility * commercial teams need scope and payment control * technical teams need clear standards * security teams need assurance evidence * suppliers need clear responsibilities * leadership needs decision points and risk visibility ### The Agile Contract Boundary In our model, agile delivery operates inside an agreed commercial boundary. The Statement of Work defines: * the authorised work package * the phase being delivered * the outcomes expected * the deliverables * the milestones * the acceptance criteria * the customer responsibilities * the assumptions and exclusions * the commercial model * the IP position * the governance cadence The backlog then defines the day-to-day and sprint-by-sprint delivery detail. This means we can be flexible in how we solve the problem without losing control of scope, risk, cost or acceptance. ### What Agile Means for Customers For customers, agile delivery means: * seeing progress regularly * receiving early evidence rather than late surprises * making prioritisation decisions throughout delivery * validating assumptions before major spend * shaping the product or service using real feedback * understanding trade-offs between time, scope, cost and quality * receiving clearer evidence for acceptance and assurance ### What Agile Means for Delivery Teams For delivery teams, agile delivery means: * working from a prioritised backlog * delivering in short increments * demonstrating progress frequently * making blockers visible early * testing assumptions quickly * improving ways of working continuously * keeping technical, security and delivery evidence current ### What Agile Does Not Mean Agile does not mean: * uncontrolled scope * unclear responsibilities * no documentation * no plan * no commercial discipline * no acceptance criteria * unlimited change * building without evidence * bypassing security or assurance ### Our Delivery Promise We commit to making work visible, learning early, delivering in increments, managing risk actively and protecting both customer outcomes and our commercial position. ### Practical Operating Rules * Every engagement has a defined delivery phase. * Every phase has entry and exit criteria. * Every sprint or iteration has a clear objective. * Every deliverable has acceptance criteria. * Every material decision is recorded. * Every material change is controlled. * Every reusable IP asset is checked before use. * Every project maintains evidence as it delivers. * Every team reviews and improves how it works. # Core Agile Principles ### Overview Our agile principles are aligned to the GOV.UK Service Manual. They are expressed here as practical behaviours for our teams. ### 1. Focus on User Needs We start by understanding who the users are, what they need to achieve and what prevents them from succeeding today. User needs may include: * end-user needs * customer operational needs * administrator needs * support team needs * security and compliance needs * reporting and audit needs * accessibility needs * integration and data needs A user need is not the same as a feature request. A feature is one possible response to a need. Agile delivery keeps the team focused on the underlying need so that the right solution can emerge. ### 2. Deliver Iteratively We break work into manageable increments. Each increment should produce learning, value, evidence or risk reduction. Iteration allows the team to: * validate direction early * expose problems before they become expensive * adjust priorities * reduce delivery risk * show progress * improve quality continuously ### 3. Keep Improving the Service The service is never considered complete simply because a phase ends. Every phase creates evidence that should improve the next phase. Improvement may include: * simplifying user journeys * reducing support burden * improving performance * improving accessibility * reducing technical debt * improving security posture * improving monitoring * improving documentation * improving operational readiness ### 4. Keep Improving the Team Agile teams improve how they work, not just what they deliver. Teams should regularly inspect: * communication quality * decision speed * meeting effectiveness * backlog quality * handoffs * blockers * technical practices * quality practices * customer engagement * supplier coordination ### 5. Fail Fast and Learn Quickly We deliberately test risky assumptions early. The aim is not to fail carelessly. The aim is to avoid large, late and expensive failure. A fast failure is useful where it: * invalidates a weak assumption * prevents wasted build effort * clarifies a better path * produces evidence * reduces uncertainty ### 6. Keep Planning Agile planning is continuous. Plans are not abandoned; they are updated as the team learns. We maintain planning at multiple levels: * outcome plan * phase plan * roadmap * release plan * sprint or iteration plan * daily coordination ### 7. Make Work Visible Visibility is a control. The team should be able to show: * what is planned * what is in progress * what is complete * what is blocked * what is at risk * what decisions are needed * what has changed * what evidence exists ### 8. Build Quality In Quality is part of the delivery process. It is not a final inspection activity. Quality is built through: * clear acceptance criteria * good user stories * code review * testing * security review * architecture decisions * accessibility checks * performance checks * documentation * governance reviews ### 9. Protect Reusable IP We use reusable IP to accelerate delivery, but we do not lose control of it. Reusable templates, components, playbooks, code, patterns, checklists and methods must be used in line with the contract and IP rules. ### 10. Produce Evidence as We Deliver Evidence should be created naturally as work progresses. We avoid trying to reconstruct evidence at the end. Evidence may include: * research notes * decisions * prototype findings * test results * accessibility checks * security reviews * acceptance records * deployment records * metrics * retrospective actions # Agile Methods We Use ### Overview We use agile methods pragmatically. The chosen method must fit the work, team, customer environment and phase. We commonly combine: * Scrum-style sprint delivery * Kanban-style flow management * Lean thinking * user-centred design * service design * technical spikes * prototyping * continuous delivery practices ### Scrum-Style Delivery Scrum-style delivery works well when a team can plan work in short iterations. Typical sprint length: * 1 week for fast-moving discovery or alpha work * 2 weeks for most product and software delivery * 3 to 4 weeks only where customer governance or dependency cycles require it Core sprint practices: * sprint planning * daily stand-up * backlog refinement * show and tell * retrospective * sprint review or governance review ### Kanban-Style Delivery Kanban-style delivery works well where work arrives continuously or where support, live service improvement or operational tasks need steady flow. Kanban practices include: * visible board * work in progress limits * clear workflow states * explicit policies * cycle time measurement * blocker management * continuous prioritisation ### Lean Thinking Lean thinking helps us remove waste and focus on value. Examples of waste include: * building features without validated need * waiting for decisions * duplicating evidence * producing documentation nobody uses * handoffs without ownership * over-engineering too early * fixing defects that could have been prevented ### User-Centred Design User-centred design ensures services are shaped by evidence from users and their context. This includes: * user research * journey mapping * service blueprinting * usability testing * accessibility consideration * content design * assisted digital needs ### Technical Spikes A technical spike is a time-boxed investigation used to reduce uncertainty. Use a spike where the team needs to answer a question such as: * Can this integration work? * Is this technology suitable? * What is the data quality like? * What are the security constraints? * Can the system meet performance requirements? * What is the simplest viable architecture? A spike must have: * a clear question * a timebox * expected evidence * decision criteria * documented outcome ### Prototyping Prototypes are used to learn. They are not automatically production assets. Prototype types include: * paper prototype * clickable prototype * content prototype * data prototype * technical proof of concept * integration prototype * service simulation Prototype rules: * make the learning goal explicit * keep the prototype as simple as possible * do not confuse prototype code with production code * record what was learned * decide whether to continue, change direction or stop ### Method Selection Select the method based on: * uncertainty level * delivery phase * team size * customer governance needs * supplier involvement * technical complexity * release frequency * operational risk * assurance requirements ### Default Method Pattern Our default pattern is: * Discovery: user-centred research, service design, technical discovery and short Kanban flow * Alpha: prototypes, technical spikes, user testing and short sprint cycles * Beta: Scrum-style product build with release planning and assurance gates * Live: Kanban-style continuous improvement with roadmap-based planning * Retirement: controlled transition plan with governance checkpoints # Delivery System Explains how agile delivery is organised, including team structure, roles and the operating model used to run delivery work. # Team Model ### Overview Agile delivery depends on having the right people with the right authority working together at the right time. Teams should be multidisciplinary. A team should not be made only of engineers, only of analysts or only of managers. It should include the skills needed to understand the problem, design the service, build the solution, assure it and operate it. ### Core Roles ### Delivery Lead Owns delivery execution. Responsibilities: * delivery plan * team rhythm * sprint or flow management * RAID management * milestone tracking * reporting * customer governance coordination * blocker escalation * acceptance coordination ### Product Lead Owns product direction and prioritisation. Responsibilities: * product vision * outcomes * backlog priority * roadmap * trade-off decisions * value measurement * stakeholder alignment ### Service Designer Owns end-to-end service understanding. Responsibilities: * user journeys * service blueprints * cross-channel experience * operational handoffs * assisted digital considerations * service pain points ### User Researcher Owns user insight and research quality. Responsibilities: * research planning * recruitment approach * interviews and testing * synthesis * user needs evidence * usability findings * accessibility insight ### Business Analyst Owns structured analysis of business, process, rules and requirements. Responsibilities: * process mapping * requirement clarification * acceptance criteria * dependency analysis * data and rule mapping * operational impacts ### Technical Lead Owns technical direction. Responsibilities: * architecture * engineering standards * technical decisions * integration approach * technical risk * code quality * technical assurance ### Security Lead Owns security and assurance alignment. Responsibilities: * security requirements * data handling * threat modelling * access model * vulnerability management * risk treatment * security evidence ### Engineers Own technical build and implementation. Responsibilities: * code delivery * tests * peer review * deployment scripts * documentation * defect resolution ### Test and Quality Lead Owns test approach and quality evidence. Responsibilities: * test strategy * acceptance testing * regression testing * defect management * evidence capture * quality reporting ### Commercial Lead Owns commercial alignment. Responsibilities: * Statement of Work interpretation * change control * milestone and payment alignment * contract assumptions * IP considerations * supplier commercial alignment ### Supplier Lead Owns supplier coordination where subcontractors are used. Responsibilities: * supplier onboarding * supplier scope clarity * delivery dependencies * supplier reporting * supplier acceptance evidence * flow-down requirements ### Customer Roles Customers should identify: * senior responsible owner * product owner or business owner * operational owner * technical owner * security owner * data owner * subject matter experts * acceptance approver ### Team Size Guidance A good agile team is small enough to communicate quickly and large enough to contain the required skills. Where teams grow, split by product, service area, workstream or capability rather than creating one oversized team. ### Role Clarity Rules * Every backlog item must have an owner. * Every deliverable must have an acceptance owner. * Every risk must have an owner. * Every decision must have a decision-maker. * Every supplier task must have an internal accountable owner. # Working Environment and Cadence ### Overview The working environment should make collaboration, visibility and decision-making easy. Agile delivery works best when teams can communicate frequently, inspect progress and resolve blockers quickly. ### Delivery Workspace Every engagement should have an agreed delivery workspace that includes: * documentation location * backlog tool * roadmap location * RAID log * decision log * change log * reporting location * communication channels * repository links * design or research workspace * assurance evidence location ### Communication Channels Teams should agree which channel is used for which purpose. Example: | Channel | Purpose | Record Required | | ------------------- | ------------------------------------- | ------------------ | | Email | formal approvals and external records | yes | | Chat | day-to-day coordination | only if material | | Backlog tool | work tracking | yes | | Document repository | controlled documents and evidence | yes | | Video call | ceremonies and workshops | notes where needed | ### Delivery Cadence A standard cadence may include: * daily stand-up * weekly customer checkpoint * weekly internal delivery review * weekly risk and issue review * fortnightly show and tell * fortnightly retrospective * monthly steering review * milestone acceptance review ### Daily Stand-Up Purpose: * align the team * expose blockers * coordinate work * maintain momentum Questions: * What changed since the last stand-up? * What is being worked on now? * What is blocked? * What decision or support is needed? ### Sprint Planning Purpose: * confirm sprint objective * select work from backlog * confirm capacity * identify dependencies * agree acceptance approach Outputs: * sprint goal * sprint backlog * owners * dependencies * risks * planned review point ### Backlog Refinement Purpose: * improve future work items * split large items * clarify acceptance criteria * identify dependencies * prepare for future planning Good refinement produces backlog items that are small, clear, valuable and testable. ### Show and Tell Purpose: * demonstrate progress * gather feedback * keep stakeholders engaged * reduce surprise * support evidence-based decisions Show and tell should demonstrate real work, not only slides. It may include prototypes, research findings, service journeys, test results, technical evidence, data insights or working software. ### Retrospective Purpose: * improve how the team works * identify friction * agree practical improvements * track whether previous improvements worked Retrospective outputs should be specific actions with owners and dates. ### Governance Review Purpose: * review progress against plan * review risks and issues * review milestone status * confirm decisions * manage commercial or scope matters * escalate blockers ### Meeting Rules * Every recurring meeting must have a purpose. * Every decision should be recorded. * Every action should have an owner and date. * Meetings that do not add value should be changed or removed. # Backlog, User Stories and Definition of Done ### Overview The backlog is the living plan for delivery. It turns outcomes, user needs, technical work, security tasks, defects and operational improvements into visible, prioritised work. ### Backlog Content A healthy backlog may include: * user stories * research tasks * design tasks * technical tasks * integration tasks * security tasks * data tasks * testing tasks * documentation tasks * support tasks * defects * technical debt items * assurance tasks * supplier tasks ### User Story Format A user story should normally describe the user, the need and the value. Example: ```markdown As a [type of user] I need [capability or outcome] So that [benefit or reason] ``` ### Good User Stories Good user stories are: * grounded in user need * small enough to deliver * clear enough to estimate * testable * linked to acceptance criteria * free from unnecessary solution bias * prioritised * owned ### Acceptance Criteria Acceptance criteria define what must be true for the work to be accepted. Good acceptance criteria are: * objective * testable * specific * understandable * linked to the story or deliverable * capable of evidence Example: ```markdown Given an authorised user is viewing the case dashboard When they filter by status Then the dashboard only displays cases matching the selected status And the filter state is clearly visible And the result count is updated ``` ### Definition of Ready A backlog item is ready when: * the objective is clear * the user or stakeholder need is understood * acceptance criteria are drafted * dependencies are known * required inputs are available or planned * security or data implications are identified * the team can estimate the work * the item is small enough for the planned iteration ### Definition of Done A backlog item is done when: * acceptance criteria are met * code or artefacts are reviewed where applicable * tests are complete * security considerations are addressed * documentation is updated * evidence is stored * stakeholders have reviewed where required * no critical defects remain * the item is marked complete in the backlog ### Backlog Hygiene The backlog should be reviewed regularly to remove: * duplicate items * stale items * unclear items * items outside the Statement of Work * items with no owner * items with no visible value ### Backlog and Scope Control Not every backlog item is automatically in scope. The Statement of Work defines the authorised scope. The backlog explains how that scope is delivered. Where a new backlog item materially changes scope, cost, timeline, risk, acceptance or IP position, it must be assessed through change control. ### Traceability Where appropriate, backlog items should trace to: * outcome * user need * deliverable * milestone * acceptance criterion * risk * decision * release # Roadmaps, Prioritisation and Planning ### Overview Planning is continuous in agile delivery. We plan enough to create direction, alignment and confidence, while keeping enough flexibility to respond to learning. ### Roadmap Purpose A roadmap shows the direction of travel. It explains how outcomes will be approached over time. A roadmap should help people understand: * the vision * the major phases * the expected sequence of work * the main releases or increments * key dependencies * major risks * decision points * intended value * confidence level ### Roadmap Rules A useful roadmap is: * simple enough to understand * visible to the right stakeholders * reviewed regularly * focused on outcomes rather than fixed feature promises * honest about uncertainty * connected to the backlog * connected to governance decisions ### Planning Levels We plan at five levels: ### 1. Outcome Planning Defines why the work matters. Typical questions: * What outcome are we trying to create? * Who benefits? * How will success be measured? * What risk are we reducing? ### 2. Phase Planning Defines what must be achieved in discovery, alpha, beta, live or retirement. Typical questions: * What evidence is needed by the end of the phase? * What decision will the phase support? * What outputs are required? * What are the entry and exit criteria? ### 3. Roadmap Planning Defines the expected sequence of work. Typical questions: * What should happen first? * What depends on what? * Where are the decision points? * Where should we build, test, release or stop? ### 4. Release Planning Defines what will be released and when. Typical questions: * What is included in the release? * What is excluded? * What acceptance evidence is required? * What operational readiness is needed? ### 5. Sprint or Flow Planning Defines what the team is doing now. Typical questions: * What is the immediate objective? * What can the team complete? * What blockers exist? * What does done mean? ### Prioritisation Criteria We prioritise based on: * user value * customer value * risk reduction * legal or regulatory need * security importance * operational importance * delivery dependency * technical dependency * effort * urgency * commercial impact * learning value ### MoSCoW Prioritisation MoSCoW can be used where helpful: * Must have: essential to the phase or release * Should have: important but not essential * Could have: useful if capacity allows * Won't have now: not included in the current timebox MoSCoW should not be used as a substitute for hard trade-off decisions. If everything is marked must-have, prioritisation has failed. ### Prioritisation by Phase Discovery priorities: * understand the problem * identify users * identify constraints * test whether further work is justified Alpha priorities: * test risky assumptions * compare options * learn quickly * avoid premature production build Beta priorities: * build usable service increments * validate with real users * assure security and quality * prepare for live Live priorities: * maintain service health * improve performance * respond to user evidence * manage technical debt Retirement priorities: * protect users * protect data * manage transition * decommission safely ### Planning Evidence Planning artefacts should include: * roadmap * backlog * release plan * milestone plan * sprint plan * dependency log * decision log * RAID log # Measuring Progress and Performance ### Overview Agile progress is measured through evidence, not optimism. We use a balanced view of progress that includes delivery output, user value, quality, risk, service health and commercial position. ### Delivery Progress Measures Delivery progress may include: * backlog items completed * sprint goal achieved * milestones completed * deliverables accepted * blockers removed * risks reduced * decisions made * releases completed * defects resolved * evidence produced ### User and Service Measures User and service measures may include: * task completion rate * user satisfaction * support tickets * call volume * abandonment rate * time to complete task * accessibility findings * research findings * service analytics * feedback themes ### Technical Measures Technical measures may include: * test pass rate * defect trends * deployment frequency * failed deployment rate * recovery time * performance results * security vulnerabilities * dependency health * code review completion * technical debt items ### Commercial Measures Commercial measures may include: * milestone status * accepted deliverables * invoice readiness * change request status * scope variance * customer dependency performance * supplier performance * remaining budget ### Risk and Assurance Measures Risk and assurance measures may include: * open high risks * open high issues * overdue decisions * unresolved dependencies * security findings * data protection actions * accessibility actions * audit evidence gaps ### Status Reporting Status should be honest and evidence-based. ### Green Delivery is on track. No material intervention is required. ### Amber Delivery is at risk. Management action, customer decision or scope trade-off may be required. ### Red Delivery is materially off track. Immediate escalation is required. ### Good Reporting Questions A good report answers: * What has changed? * What has been completed? * What value or evidence was produced? * What is planned next? * What is blocked? * What decisions are needed? * What risks or issues require attention? * Is scope still aligned to the Statement of Work? * Are milestones and acceptance criteria still achievable? ### Avoiding Vanity Metrics Do not rely only on measures that look positive but do not explain real progress. Weak measures include: * number of meetings held * number of documents produced * percentage complete without evidence * effort spent without outcome * activity without user or customer value ### Evidence Standard Where a measure is used for governance, acceptance or payment, it should be supported by evidence. # Governance and Assurance ### Overview Governance ensures that delivery remains controlled, visible and aligned to agreed outcomes. Assurance ensures that the work is fit for purpose and risks are understood. Governance should help delivery. It should not create unnecessary delay or paperwork. ### Governance Layers We use four governance layers. ### 1. Team Governance Daily and weekly management of work. Includes: * stand-ups * sprint planning * backlog refinement * retrospectives * technical reviews * risk reviews ### 2. Delivery Governance Management of delivery progress, milestones, blockers and dependencies. Includes: * weekly delivery review * customer checkpoint * milestone review * acceptance review * change review ### 3. Commercial Governance Management of commercial position. Includes: * Statement of Work alignment * payment milestones * change control * assumptions and dependencies * supplier commercial position * IP position ### 4. Assurance Governance Management of quality, security, data, technical and operational readiness. Includes: * architecture review * security review * data review * test review * accessibility review * live readiness review ### Core Governance Artefacts Every engagement should maintain: * delivery plan * roadmap * backlog * RAID log * decision log * change log * dependency log * milestone tracker * acceptance register * evidence register * commercial tracker ### Decision-Making Material decisions should record: * decision made * date * decision owner * context * options considered * evidence used * impact * follow-up actions ### Risk and Issue Management A risk is something that may happen. An issue is something that has happened. Each risk or issue should have: * description * owner * impact * probability where relevant * severity * mitigation or action * due date * status * escalation route ### Change Control Change control is required where a proposed change affects: * scope * deliverables * acceptance criteria * timeline * cost * resourcing * risk * security * data * IP * supplier obligations ### Assurance Gates Assurance gates are used where the team needs confidence before proceeding. Examples: * discovery exit review * alpha exit review * beta live readiness review * security review * architecture review * release approval * retirement approval ### Assurance Evidence Evidence may include: * research findings * prototypes * test results * accessibility checks * architecture decisions * security review records * data protection assessments * operational readiness checklists * deployment logs * acceptance certificates ### Governance Rule No governance meeting should exist without a decision, risk, dependency, milestone, acceptance or assurance purpose. # Delivery Phases Explains the agile delivery lifecycle, including each phase, its purpose, typical activities, outputs and exit criteria. # Discovery ### Purpose Discovery is used to understand the problem before committing to a solution. The goal is to learn enough to decide whether to stop, proceed, reshape the opportunity or move into alpha. ### When to Use This Phase Use discovery when the problem is unclear, the users are not well understood, the customer is asking for a solution before the need has been validated, significant constraints may exist, or a commercial commitment would be risky without more evidence. ### Primary Decision At the end of this phase, we should be able to answer: > Is there a real problem worth solving, and do we know enough to define a credible alpha or next phase? ### Core Questions * Who are the users? * What are they trying to achieve? * What problem are we solving? * What evidence shows the problem exists? * What policy, operational, legal, security or technical constraints apply? * What has already been tried? * What data exists? * What risks are most important? * What options should be explored next? * Is there enough value to justify further investment? ### Key Activities * stakeholder interviews * user research * current-state mapping * journey mapping * service blueprinting * technical discovery * data discovery * security discovery * policy and process review * supplier and dependency mapping * risk assessment * opportunity sizing * initial roadmap development ### Expected Outputs * problem statement * user needs summary * stakeholder map * current-state assessment * journey maps * constraints log * risks and assumptions log * options assessment * alpha recommendation * initial roadmap * commercial recommendation * draft scope for next phase ### Entry Criteria * sponsor identified * initial opportunity or problem described * access to stakeholders agreed * discovery timebox agreed * commercial authority in place * security and confidentiality requirements understood ### Exit Criteria * problem is clearly described * priority users and needs are identified * constraints and dependencies are visible * major risks are recorded * options for alpha or next step are defined * recommendation is evidence-based * customer decision is recorded ### Evidence to Capture * research plan * interview notes * research synthesis * journey maps * technical discovery notes * data assessment * risk log * decision log * recommendation report * show and tell outputs ### Commercial and Statement of Work Considerations * keep discovery scope tightly timeboxed * avoid committing to build outputs during discovery * record assumptions for the next Statement of Work * identify customer dependencies early * separate discovery recommendations from contractual commitments ### IP and Accelerator Considerations * use discovery templates and interview guides as Background IP * do not place customer confidential content into reusable templates * identify reusable patterns that may accelerate alpha * record any customer-specific materials separately ### Security, Data and Assurance Considerations * classify information before collection * confirm whether personal or sensitive data is involved * limit access to research and customer materials * identify likely assurance requirements for later phases ### Common Risks * solution bias * insufficient user access * stakeholder assumptions treated as evidence * unclear sponsor * discovery turning into build * hidden technical constraints * unrecorded customer dependencies ### Practical Checklist * Agree discovery goal and timebox * Confirm stakeholders and user groups * Prepare research and workshop plan * Set up evidence repository * Run research and analysis * Map constraints and dependencies * Review risks and assumptions * Develop options and recommendation * Run discovery playback * Record decision on next step # Alpha ### Purpose Alpha is used to test possible solutions and the riskiest assumptions. The goal is to learn which approach is most likely to work before building at scale. ### When to Use This Phase Use alpha when discovery has identified a valuable problem but there are still major uncertainties about the right solution, technical feasibility, user journey, data flow, operating model or assurance route. ### Primary Decision At the end of this phase, we should be able to answer: > Which solution option should move forward, and what evidence supports that decision? ### Core Questions * Which assumptions are most risky? * Which options should we test? * Can users complete the key journeys? * Can the technical approach work? * Can required data be accessed and shared safely? * What security or assurance barriers exist? * What should be built in beta? * What should be stopped or discarded? ### Key Activities * prototype creation * user testing * technical spikes * architecture options analysis * integration proof of concept * data feasibility testing * service design iteration * content design testing * accessibility review * security risk exploration * operating model design * beta backlog development ### Expected Outputs * tested prototypes * user testing findings * technical feasibility evidence * architecture recommendation * data feasibility assessment * security considerations * preferred option * beta backlog * beta roadmap * updated risks * commercial assumptions for beta ### Entry Criteria * discovery recommendation approved * alpha objectives defined * riskiest assumptions identified * team roles agreed * prototype tooling agreed * security constraints understood * commercial authority in place ### Exit Criteria * key assumptions tested * preferred approach selected * evidence supports the recommendation * beta scope is understood * major risks and constraints are recorded * technical approach is credible * customer decision is recorded ### Evidence to Capture * prototype links or screenshots * research findings * test results * architecture decision records * spike reports * accessibility notes * security notes * beta backlog * show and tell outputs * alpha recommendation report ### Commercial and Statement of Work Considerations * make clear that prototype work is not production build unless agreed * define which alpha outputs are deliverables * update assumptions for beta pricing and scope * identify any change from discovery expectations * prepare acceptance criteria for beta deliverables ### IP and Accelerator Considerations * use accelerators to build prototypes quickly * label prototype code appropriately * avoid accidentally transferring reusable components * record any reusable improvements created during alpha * confirm third-party or open-source components before wider use ### Security, Data and Assurance Considerations * do not expose real sensitive data in prototypes unless approved * review data flows early * identify likely threat model areas * confirm access control implications * identify security evidence needed for beta and live ### Common Risks * prototype mistaken for production service * testing too many options weakly * not testing the riskiest assumptions * user research gaps * technical spike results not documented * accessibility left too late * beta scope based on opinion rather than evidence ### Practical Checklist * Confirm alpha questions * Rank riskiest assumptions * Plan prototypes and spikes * Run user testing * Run technical feasibility tests * Review security and data implications * Compare options * Develop beta backlog and roadmap * Run alpha playback * Record proceed, stop or reshape decision # Beta ### Purpose Beta is where the preferred alpha approach is built and tested with real users. The goal is to develop a usable, secure and supportable service or product and prepare it for live operation. ### When to Use This Phase Use beta when alpha evidence supports a preferred solution and the customer is ready to build, test and release usable increments with real users. ### Primary Decision At the end of this phase, we should be able to answer: > Is the service good enough, safe enough and operationally ready enough to move into live use? ### Core Questions * What is the minimum viable service? * Which users will access private beta? * When can public or wider beta begin? * What must be tested before live? * What support model is needed? * What metrics will show performance? * What security and data evidence is required? * What defects or risks block live release? ### Key Activities * production-grade build * private beta release * public or wider beta release where appropriate * user research with real users * accessibility testing * integration testing * security testing * performance testing * service support design * operational readiness planning * release planning * defect management * documentation ### Expected Outputs * working service or product * release notes * tested user journeys * support model * operational documentation * security evidence * performance evidence * accessibility evidence * service metrics * live readiness assessment * updated roadmap ### Entry Criteria * alpha recommendation approved * beta Statement of Work agreed * backlog prioritised * team mobilised * environments available or planned * security approach agreed * acceptance model agreed ### Exit Criteria * service works for intended users * critical user journeys are tested * security and assurance requirements are met or risk-accepted * support model is ready * monitoring is in place * performance is acceptable * live release decision is recorded ### Evidence to Capture * completed backlog items * test evidence * user research findings * defect log * accessibility report * security review * deployment records * monitoring evidence * support readiness checklist * live readiness report * acceptance certificates ### Commercial and Statement of Work Considerations * tie milestones to evidence and accepted deliverables * use change control for material scope changes * track customer dependencies that affect delivery * maintain payment evidence * ensure supplier deliverables support acceptance ### IP and Accelerator Considerations * separate reusable components from customer-specific outputs where possible * confirm ownership and licence of any foreground IP * record open-source components * avoid embedding restricted customer material into reusable assets * update accelerator library only after IP review ### Security, Data and Assurance Considerations * apply secure development practices * manage secrets properly * run vulnerability checks * confirm access controls * test data handling * prepare security evidence * confirm incident and support routes before live ### Common Risks * beta treated as a full uncontrolled build * private beta feedback ignored * operational support designed too late * security evidence delayed * performance issues discovered at live gate * scope expands without change control * supplier tasks not integrated into release plan ### Practical Checklist * Confirm beta scope and acceptance criteria * Set up environments and repositories * Build and test increments * Run private beta with selected users * Capture and prioritise feedback * Run security, accessibility and performance checks * Prepare support model * Prepare live readiness evidence * Run beta exit review * Record live decision # Live ### Purpose Live is the sustainable operation and continuous improvement phase. The goal is to run the service safely, monitor performance and keep improving it based on evidence. ### When to Use This Phase Use live when the service has passed readiness checks, is being used operationally and requires ongoing support, improvement and governance. ### Primary Decision At the end of this phase, we should be able to answer: > How do we keep the service healthy, valuable, secure and improving over time? ### Core Questions * Is the service meeting user needs? * Are service levels acceptable? * What are users struggling with? * What incidents or defects are occurring? * What technical debt is emerging? * What security risks need treatment? * What should be improved next? * Is the service still cost-effective? ### Key Activities * service monitoring * incident management * support management * user feedback analysis * performance analysis * security monitoring * vulnerability management * release management * continuous improvement * technical debt management * roadmap review * service reporting ### Expected Outputs * service performance reports * support reports * incident records * improvement backlog * release notes * security updates * technical debt register * service roadmap * operational review records ### Entry Criteria * live readiness approved * support model in place * monitoring in place * incident process agreed * security controls implemented * service owner identified * operational documentation complete ### Exit Criteria * live continues until the service is transitioned, replaced or retired * where retirement is needed, retirement criteria and plan are agreed ### Evidence to Capture * analytics reports * uptime and monitoring records * incident logs * support metrics * research findings * release records * security scan results * change records * service review minutes ### Commercial and Statement of Work Considerations * define live support scope clearly * separate support, maintenance and enhancement work * track service credits or service levels where applicable * use change control for new features outside scope * align recurring charges to agreed service obligations ### IP and Accelerator Considerations * continue improving reusable accelerators where permitted * record operational improvements that may be reusable * maintain separation between customer-specific configuration and reusable components * review third-party component obligations during service life ### Security, Data and Assurance Considerations * monitor vulnerabilities * review access regularly * manage incidents promptly * maintain audit evidence * review data retention * test resilience and recovery where required ### Common Risks * support scope creep * technical debt ignored * no clear service owner * metrics not reviewed * security patching delayed * knowledge concentrated in one person * improvement backlog not prioritised ### Practical Checklist * Confirm service ownership * Review service metrics * Review support tickets and incidents * Review user feedback * Prioritise improvement backlog * Plan releases * Review security and access * Review technical debt * Report service health * Escalate retirement or transition triggers where needed # Retirement ### Purpose Retirement is used when a service, product, component or process is no longer needed, is being replaced or is no longer cost-effective or safe to operate. ### When to Use This Phase Use retirement when user need has ended, policy has changed, a replacement service is available, usage is too low, cost is too high, technology is obsolete or security risk is unacceptable. ### Primary Decision At the end of this phase, we should be able to answer: > How do we safely close, transition or decommission the service while protecting users, data, operations and contractual obligations? ### Core Questions * Why is retirement needed? * Who will be affected? * What alternative service or process exists? * What data must be retained, migrated, archived or deleted? * What suppliers are involved? * What user communications are required? * What redirects or integrations must be managed? * What contractual obligations survive? ### Key Activities * retirement assessment * user impact assessment * communications planning * data retention review * migration planning * supplier exit planning * access removal planning * redirect planning * decommissioning * archive and evidence capture * final reporting ### Expected Outputs * retirement decision record * impact assessment * communications plan * migration plan * data handling record * decommissioning plan * supplier exit record * access removal evidence * final closure report ### Entry Criteria * retirement trigger identified * service owner engaged * customer decision route agreed * impact assessment initiated * data and security owners identified ### Exit Criteria * users are informed or transitioned * data is retained, migrated, archived or deleted appropriately * access is removed * systems are decommissioned * suppliers are exited where required * final evidence is stored * closure is approved ### Evidence to Capture * retirement approval * communications evidence * data handling evidence * migration evidence * access removal logs * decommissioning records * supplier closure records * final report ### Commercial and Statement of Work Considerations * check termination and exit obligations * confirm support end date * confirm final payment position * agree any transition assistance * close open change requests and acceptance items ### IP and Accelerator Considerations * confirm what customer materials must be returned or deleted * preserve company Background IP * record reusable lessons learned * avoid retaining customer confidential material in reusable assets ### Security, Data and Assurance Considerations * remove access promptly * protect retained records * confirm data deletion or retention evidence * decommission credentials and integrations * review audit requirements ### Common Risks * users not informed * data retained without basis * redirects missed * supplier access left open * contractual exit obligations missed * archive incomplete * service dependencies overlooked ### Practical Checklist * Confirm retirement decision route * Assess users and operational impact * Create communications plan * Create data retention or migration plan * Plan supplier exit * Plan redirects and integration closure * Remove access * Decommission service * Store closure evidence * Complete final review # Operating Controls Explains the controls used to manage agile delivery, including governance, assurance, reporting, risk, change and performance tracking. *** # Commercial, IP and Statement of Work Alignment ### Overview Our agile process is designed to operate inside a controlled commercial model. Agile gives flexibility in how we solve problems. It does not remove the need for a clear Statement of Work, commercial authority, acceptance criteria or IP protection. ### Statement of Work Alignment Every phase should be linked to a Statement of Work or other approved commercial authority. The Statement of Work should define: * phase * objectives * scope * out of scope * deliverables * milestones * acceptance criteria * assumptions * customer responsibilities * dependencies * team model * governance cadence * commercial model * IP position * security and data requirements ### Agile Scope Control The backlog can change frequently. The authorised scope cannot change informally. A backlog change may remain inside scope where it: * supports the agreed objectives * does not add material deliverables * does not change acceptance criteria materially * does not extend timeline or cost * does not introduce new material risk * does not change the IP or security position A backlog change should go through change control where it affects: * cost * timeline * deliverables * acceptance * security * data * IP * supplier obligations * material assumptions ### Milestone Alignment Milestones should be connected to evidence. A milestone should not simply say that a phase has progressed. It should identify what has been delivered, reviewed or accepted. Examples: * discovery findings accepted * alpha prototype playback completed * beta release deployed to private beta users * live readiness evidence approved * support model accepted ### Acceptance Criteria Acceptance criteria should be agreed before delivery starts. They may be refined as learning emerges, but material changes must be approved. Acceptance criteria should be: * objective * testable * linked to deliverables * capable of evidence * commercially meaningful * realistic for the phase ### IP Categories We classify IP as: * Background IP: pre-existing company assets, templates, methods, code, frameworks and know-how * Foreground IP: IP created specifically during the project * Customer IP: materials, data, documents and systems provided by the customer * Third-party IP: externally owned components or services * Open-source components: components governed by open-source licences ### IP Reuse Principles * Reuse approved company assets before rebuilding. * Do not transfer Background IP unless expressly agreed. * Check licence terms before using third-party or open-source components. * Do not contaminate reusable assets with customer confidential information. * Record improvements that may be reusable. * Confirm Foreground IP treatment in the contract or Statement of Work. ### Accelerator Use Accelerators may include: * discovery interview guides * service blueprint templates * backlog templates * architecture patterns * code scaffolds * deployment pipelines * test scripts * security evidence packs * acceptance criteria libraries * governance templates Accelerators should be used when they are relevant, current, secure, legally usable and appropriate to the customer environment. ### Commercial Health Checks At each governance review, ask: * Are we still inside the agreed Statement of Work? * Are deliverables and acceptance criteria still valid? * Are customer dependencies being met? * Are changes being controlled? * Are milestones and payment triggers supported by evidence? * Is the IP position still clear? * Are supplier outputs aligned to customer obligations? # Supplier and Subcontractor Alignment ### Overview Suppliers and subcontractors can support delivery, but they must operate inside the same agile, commercial, IP and security controls as the core team. ### Supplier Engagement Principles * Use suppliers only where there is a clear need. * Define supplier scope clearly. * Flow down relevant customer obligations. * Protect customer and company information. * Confirm IP ownership and licensing. * Confirm security and access requirements. * Track supplier work in the delivery governance model. * Do not allow supplier work to become invisible. ### Supplier Onboarding Before a supplier starts work, confirm: * signed agreement or work order * scope and deliverables * acceptance criteria * reporting cadence * security obligations * confidentiality obligations * IP position * access approvals * tools and repositories * escalation route * customer restrictions ### Supplier Backlog Integration Supplier work should be visible in the backlog or dependency log. For each supplier item, record: * owner * deliverable * due date * dependency * acceptance criteria * status * risks * evidence required ### Supplier Governance Supplier governance should include: * regular status review * risk and issue review * deliverable review * evidence review * security review where relevant * change review ### Flow-Down Requirements Supplier obligations may need to include: * confidentiality * data protection * security controls * audit support * IP assignment or licence * open-source restrictions * customer policy compliance * incident notification * personnel requirements * insurance requirements * acceptance and remediation obligations ### Supplier Risks Common supplier risks include: * late delivery * unclear acceptance criteria * poor quality * weak documentation * access delays * security non-compliance * IP uncertainty * dependency on a single specialist * lack of customer environment knowledge ### Supplier Exit When supplier involvement ends, confirm: * deliverables accepted * documentation received * access removed * customer data returned or deleted * IP position recorded * open defects assigned * final invoice evidence complete * lessons learned captured # Security, Data and Assurance ### Overview Security, data protection and assurance must be built into delivery from the beginning. They are not final-stage activities. ### Security by Phase ### Discovery Focus on identifying security, data and assurance constraints. Activities: * identify data types * identify likely access requirements * identify customer security policies * identify hosting and integration constraints * identify assurance obligations ### Alpha Focus on testing security assumptions. Activities: * explore data flow options * assess integration risks * identify threat areas * test feasibility of secure approaches * avoid unnecessary real sensitive data ### Beta Focus on implementing secure controls and producing evidence. Activities: * secure coding * code review * dependency scanning * vulnerability management * access control implementation * test evidence * security review ### Live Focus on monitoring, patching, incident response and continuous assurance. Activities: * vulnerability monitoring * access review * incident management * logging and monitoring * backup and recovery review * security reporting ### Retirement Focus on secure closure. Activities: * access removal * data deletion or retention * archive protection * integration closure * credential removal * decommissioning evidence ### Data Classification Projects should classify data before handling it. Possible classifications: * public * internal * confidential * customer confidential * personal data * sensitive operational data * special category personal data where applicable ### Access Control Access should follow: * least privilege * named accounts * multi-factor authentication where required * role-based access * time-bound access * regular review * prompt removal ### Assurance Evidence Assurance evidence may include: * security requirements * architecture decision records * data flow maps * access control matrix * vulnerability scan results * penetration test reports where applicable * remediation records * risk acceptance records * release approvals * operational readiness checklist ### Security Risk Acceptance Security risks must not be accepted informally. A risk acceptance should record: * risk description * impact * likelihood * mitigation * residual risk * accepting authority * review date * expiry or condition ### Minimum Security Questions Every project should ask: * What data will we handle? * Who needs access? * Where will data be stored? * How will data move between systems? * What logging is required? * What security controls are mandatory? * What evidence will the customer need? * What happens if there is an incident? # Templates and Checklists Provides practical templates and checklists for planning, governing, assuring and evidencing agile delivery work. *** # Phase Entry and Exit Checklists ### Discovery Entry Checklist * Sponsor identified * Problem or opportunity described * Discovery timebox agreed * Commercial authority confirmed * Stakeholder access agreed * Research access agreed * Security constraints identified * Evidence repository created ### Discovery Exit Checklist * Problem statement completed * User needs identified * Current state mapped * Constraints recorded * Risks and assumptions recorded * Options assessed * Recommendation prepared * Alpha or next-phase scope drafted * Decision recorded ### Alpha Entry Checklist * Discovery recommendation approved * Alpha questions agreed * Riskiest assumptions ranked * Team roles confirmed * Prototype approach agreed * Technical spike plan created * Security and data constraints understood * Commercial authority confirmed ### Alpha Exit Checklist * Prototypes tested * User feedback captured * Technical feasibility assessed * Security and data implications understood * Preferred option selected * Beta backlog created * Beta roadmap drafted * Commercial assumptions updated * Proceed, stop or reshape decision recorded ### Beta Entry Checklist * Beta Statement of Work agreed * Backlog prioritised * Acceptance criteria agreed * Environments planned * Engineering standards confirmed * Security approach confirmed * Release approach agreed * Support model design started ### Beta Exit Checklist * Critical journeys tested * Service or product working for real users * Security evidence complete or risk-accepted * Accessibility evidence complete where required * Performance evidence reviewed * Support model ready * Monitoring in place * Live readiness approved * Acceptance recorded ### Live Entry Checklist * Service owner confirmed * Support process live * Monitoring active * Incident process agreed * Access controls reviewed * Operational documentation complete * Release process agreed * Service metrics agreed ### Live Review Checklist * Service performance reviewed * User feedback reviewed * Support tickets reviewed * Incidents reviewed * Security vulnerabilities reviewed * Improvement backlog prioritised * Technical debt reviewed * Roadmap updated ### Retirement Entry Checklist * Retirement trigger identified * Service owner engaged * User impact assessed * Data impact assessed * Supplier impact assessed * Contractual exit obligations reviewed * Retirement approval route agreed ### Retirement Exit Checklist * Users informed or transitioned * Data retained, migrated, archived or deleted * Access removed * Integrations closed * Suppliers exited * Redirects implemented where required * Service decommissioned * Closure evidence stored * Final approval recorded # Governance Templates ### Weekly Delivery Report Template ```markdown # Weekly Delivery Report ## Reporting Period [Start date] to [End date] ## Overall Status Green / Amber / Red ## Executive Summary [Brief summary of progress, risks and decisions.] ## Completed This Period - [Completed item] ## Planned Next Period - [Planned item] ## Milestone Status | Milestone | Status | Due Date | Evidence | Notes | |---|---|---|---|---| | [Milestone] | [Status] | [Date] | [Evidence] | [Notes] | ## Risks and Issues | ID | Type | Description | Owner | Rating | Action | Due Date | |---|---|---|---|---|---|---| | [ID] | Risk/Issue | [Description] | [Owner] | [Rating] | [Action] | [Date] | ## Decisions Required | Decision | Owner | Required By | Impact if Delayed | |---|---|---|---| | [Decision] | [Owner] | [Date] | [Impact] | ## Change Control | Change | Status | Impact | Decision Needed | |---|---|---|---| | [Change] | [Status] | [Impact] | [Decision] | ## Support Required [Support required from customer, internal teams or suppliers.] ``` ### Decision Log Template ```markdown # Decision Log | ID | Date | Decision | Owner | Evidence | Impact | Follow-Up | |---|---|---|---|---|---|---| | D-001 | [Date] | [Decision] | [Owner] | [Evidence] | [Impact] | [Action] | ``` ### Change Request Template ```markdown # Change Request ## ID [CR-000] ## Title [Change title] ## Description [Describe the change.] ## Reason [Why is this change needed?] ## Impact | Area | Impact | |---|---| | Scope | [Impact] | | Timeline | [Impact] | | Cost | [Impact] | | Risk | [Impact] | | Security | [Impact] | | Data | [Impact] | | IP | [Impact] | | Acceptance | [Impact] | | Supplier | [Impact] | ## Recommendation Approve / Reject / Defer ## Approval Customer approver: Supplier approver: Effective date: ``` ### Acceptance Record Template ```markdown # Acceptance Record ## Deliverable [Deliverable name] ## Statement of Work Reference [Reference] ## Version [Version] ## Submission Date [Date] ## Acceptance Criteria | Criterion | Evidence | Result | |---|---|---| | [Criterion] | [Evidence] | Pass/Fail | ## Decision Accepted / Rejected / Accepted with observations ## Comments [Comments] ## Approver Name: Role: Date: ``` # Research, Backlog and Metrics Templates ### Research Plan Template ```markdown # Research Plan ## Research Objective [What do we need to learn?] ## Research Questions - [Question] ## Users or Participants - [User group] ## Method Interview / usability test / survey / analytics review / observation / workshop ## Recruitment Criteria [Criteria] ## Materials Required - [Material] ## Risks and Ethics [Privacy, consent, sensitivity or accessibility considerations] ## Outputs - findings summary - user needs - recommendations - evidence notes ``` ### User Need Template ```markdown As a [user type] I need to [achieve outcome] So that [reason or value] Evidence: - [Research finding or source] ``` ### Backlog Item Template ```markdown # Backlog Item ## Title [Title] ## Type User story / technical task / research task / security task / defect / documentation ## Description [Description] ## Value [Why this matters] ## Acceptance Criteria - [Criterion] ## Dependencies - [Dependency] ## Security or Data Considerations [Considerations] ## Estimate [Estimate] ## Owner [Owner] ``` ### Service Metric Template ```markdown # Service Metric ## Metric Name [Metric] ## Purpose [What decision does this support?] ## Data Source [Source] ## Frequency [Daily / weekly / monthly] ## Owner [Owner] ## Target or Threshold [Target] ## Action if Threshold Breached [Action] ``` ### Retrospective Action Template ```markdown # Retrospective Action ## Observation [What happened?] ## Impact [Why it matters] ## Action [What will change?] ## Owner [Owner] ## Due Date [Date] ## Review Outcome [Did it work?] ``` # Glossary ### Agile An iterative approach to delivery that focuses on user needs, frequent learning, visible progress and continuous improvement. ### Alpha A phase used to test possible solutions and risky assumptions before committing to full build. ### Acceptance Criteria The agreed conditions that must be met for a deliverable, story or milestone to be accepted. ### Backlog A prioritised list of work items to be delivered or investigated by the team. ### Background IP Pre-existing intellectual property owned by the company or a third party before the project starts. ### Beta A phase where the preferred solution is built and tested with real users before live operation. ### Change Control The process for assessing and approving material changes to scope, cost, time, risk, acceptance, security, data or IP. ### Definition of Done The agreed standard that must be met before work is considered complete. ### Definition of Ready The agreed standard that must be met before work is ready for delivery planning. ### Discovery A phase used to understand the problem, users, constraints and opportunities before committing to a solution. ### Foreground IP Intellectual property created during and for a specific project. ### Live The phase where a service is operated, monitored, supported and continuously improved. ### Prototype A test artifact used to learn. A prototype is not automatically production-ready. ### RAID Risks, Assumptions, Issues and Dependencies. ### Roadmap A planning artifact that shows direction, expected phases, key outcomes, dependencies and decision points. ### Statement of Work The document that defines the authorised work package, including scope, deliverables, milestones, acceptance criteria and commercial terms. ### Technical Spike A time-boxed investigation used to answer a technical question or reduce uncertainty. ### User Need A statement of what a user needs to achieve and why it matters. # Security, Vetting and Technical Assurance Playbook ### Purpose This GitBook explains how we design, govern, assure and operate secure services in high-assurance environments. It covers: * security operating model; * Secure by Design; * MOD and defence-aligned assurance; * JSP 453 alignment approach; * personnel security and vetting; * BPSS and national security vetting dependencies; * RBAC, ABAC and zero trust access models; * government security classifications; * data handling and privacy; * cyber resilience; * NCSC CAF and 10 Steps alignment; * technical secure engineering standards; * accreditation and certification readiness; * supplier and subcontractor security; * reusable templates and evidence packs. ### Operating Principle Security is a delivery discipline, not a document exercise. Every engagement must show how security is translated into requirements, design decisions, access controls, technical implementation, supplier obligations, operational monitoring, resilience arrangements and evidence. ### Core Rules * No access without identity, business need, role mapping, attribute checks and approval. * Clearance enables eligibility; it does not automatically authorise access. * No sensitive data in unapproved tools, repositories or services. * No delivery without security requirements and acceptance criteria. * No supplier access without due diligence, contractual obligations and offboarding controls. * No release without security evidence, risk review and rollback capability. * No unresolved critical security risk without accountable risk acceptance. * No defence delivery without checking the applicable MOD, customer, CSM, Def Stan, DEFCON and sponsor requirements. ### How to Read This GitBook Use the operating model sections first, then apply the technical and assurance sections to each delivery phase. The templates section is designed for copy-and-paste use in projects, Statements of Work and assurance packs. # Table of Contents ## Top Level * Home * Source Basis and Maintenance ### Security Operating Model * Security Mission and Principles * Roles, Accountabilities and RACI * Security Governance and Working Groups * Security Risk Appetite and Risk Acceptance * Security Evidence Model ### Secure by Design and Defence Alignment * Secure by Design Overview * MOD Secure by Design Responsibilities * JSP 453 Alignment Approach * MOD Cyber Security Model v4, DEFCON 658 and Def Stan 05-138 * Defence Cyber Certification Readiness ### Personnel Security and Vetting * Personnel Security Overview * Baseline Personnel Security Standard * National Security Vetting Levels * Clearance, Role and Access Mapping * Joiners, Movers and Leavers * Insider Risk and Ongoing Personnel Security * Supplier Personnel Security ### Classification, Data and Privacy * Government Security Classifications * Data Classification and Handling * OFFICIAL and OFFICIAL-SENSITIVE Controls * SECRET and TOP SECRET Handling * Need to Know and Need to Share * Privacy, Personal Data and DPIA * Records, Retention and Secure Disposal ### Identity, Access and Zero Trust * IAM Overview * RBAC Model * ABAC Model * Hybrid RBAC and ABAC * Privileged Access Management * MFA, SSO and Conditional Access * Machine Identities and Secrets * Access Reviews and Recertification * Identity Audit Logging * Zero Trust Architecture ### Cyber Resilience * Cyber Resilience Overview * NCSC CAF Mapping * NCSC 10 Steps Operating Model * Asset Management and CMDB * Vulnerability and Patch Management * Logging, Monitoring and SOC * Incident Response and Crisis Management * Backup, Disaster Recovery and Business Continuity * Threat Intelligence and Threat Modelling * Ransomware Resilience * Exercising, Lessons and Continuous Improvement ### Technical Secure by Design Standards * Architecture Security Standards * Secure SDLC * Threat Modelling * Secure Coding and Code Review * Repository and Branch Protection * CI CD and Build Pipeline Security * Dependency, SBOM and Software Supply Chain * API Security * Cloud Security * Infrastructure as Code Security * Container and Kubernetes Security * Network Security and Segmentation * Cryptography and Key Management * Secure Configuration and Hardening * Testing, Assurance and Penetration Testing ### Accreditation, Certification and Assurance * Accreditation Strategy * Cyber Essentials and Cyber Essentials Plus * ISO 27001 ISMS * Defence Cyber Certification Readiness * CAF and GovAssure Readiness * ISO 22301 Business Continuity * SOC 2, ISO 9001 and ISO 20000 * Evidence Library and Control Mapping ### Supply Chain and Subcontractor Security * Supplier Security Model * Contracting Securely and Security Schedules * Supplier Onboarding and Due Diligence * Flow Down and Subcontractor Controls * Supplier Monitoring and Offboarding ### Security Operations and Reporting * Security Operating Rhythm * Security Metrics, KPIs and KRIs * Security Exceptions and Risk Acceptance * Audit Plan and Evidence Retention ### Templates and Checklists * Security Initiation Checklist * Security Requirements Catalogue * Vetting and Access Request Template * RBAC ABAC Access Matrix Template * Threat Model Template * Security Architecture Decision Record Template * Security Risk Register Template * Incident Response Plan Template * Supplier Security Due Diligence Template * Accreditation Evidence Matrix * Control Mapping Template * JSP 453 Alignment Register Template ### Glossary * Glossary # Scope, Source Basis and Maintenance ### Purpose This playbook is a tailored security, vetting, cyber resilience and technical assurance operating model for high-assurance UK public sector, defence, enterprise and regulated delivery. It is intended to sit alongside the Company Operating Manual and the Agile Delivery Playbook. It does not replace customer policy, contract terms, accreditation authority instructions, MOD sponsor instructions, legal advice or current official guidance. ### How This Playbook Is Used * use it when shaping bids and Statements of Work; * use it when onboarding people and suppliers; * use it when designing secure systems and services; * use it when preparing assurance, accreditation and customer evidence; * use it when defining RBAC, ABAC, vetting, data handling and operational controls; * use it when establishing cyber resilience and incident response arrangements. ### Maintenance Rule Security policy, defence policy and cyber guidance change. This playbook should be reviewed at least quarterly and whenever a customer, MOD sponsor, accreditor, regulator or contract introduces new requirements. ### Source Basis The public source basis used to shape this playbook includes: * [UK Government Security - Secure by Design](https://www.security.gov.uk/policy-and-guidance/secure-by-design/) * [UK Government Security - Implementing Secure by Design](https://www.security.gov.uk/policy-and-guidance/secure-by-design/implementation/) * [MOD Cyber Security Model](https://www.gov.uk/guidance/cyber-security-model) * [Defence Standard 05-138 Issue 4 - Cyber Security for Defence Suppliers](https://www.gov.uk/government/publications/cyber-security-for-defence-suppliers-def-stan-05-138-issue-4) * [Industry Security Notice 2025/07 - Implementation of CSM v4](https://www.gov.uk/government/publications/industry-security-notices-isns) * [Government Security Classifications Policy](https://www.gov.uk/government/publications/government-security-classifications) * [UK Government Baseline Personnel Security Standard](https://www.gov.uk/government/publications/government-baseline-personnel-security-standard) * [UK Security Vetting guidance](https://www.gov.uk/government/publications/united-kingdom-security-vetting-clearance-levels) * [NCSC Cyber Assessment Framework](https://www.ncsc.gov.uk/collection/cyber-assessment-framework) * [NCSC 10 Steps to Cyber Security](https://www.ncsc.gov.uk/collection/10-steps) * [NCSC Identity and Access Management](https://www.ncsc.gov.uk/collection/10-steps/identity-and-access-management) * [NCSC Logging and Monitoring](https://www.ncsc.gov.uk/collection/10-steps/logging-and-monitoring) * [NCSC Secure Development and Deployment](https://www.ncsc.gov.uk/collection/developers-collection) * [NCSC Cloud Security Principles](https://www.ncsc.gov.uk/collection/cloud/the-cloud-security-principles) * [NCSC Zero Trust](https://www.ncsc.gov.uk/collection/zero-trust) * [GOV.UK Contracting Securely](https://www.security.gov.uk/policy-and-guidance/contracting-securely/) * [PPN 014 Cyber Essentials Scheme](https://www.gov.uk/government/publications/ppn-014-cyber-essentials-scheme) * [MOD Joint Service Publications collection](https://www.gov.uk/government/collections/joint-service-publication-jsp) ### Controlled or Customer-Specific Content Some requirements, including project-specific defence policy, JSP content and accreditation authority instructions, may not be public or may only be accessible through a relevant sponsor. This playbook therefore defines an alignment and evidence approach rather than reproducing controlled material. ### Interpretation Rule Where this playbook conflicts with an executed contract, customer security schedule, project security instruction, accreditation authority decision or current official policy, the stricter or formally binding requirement must be followed and the conflict must be recorded. # Security Operating Model Explains how security is organised, including roles, vetting, assurance activities and decision points. # Roles, Accountabilities and RACI ### Purpose This page defines the operating standard for roles, accountabilities and raci within the Security, Vetting and Technical Assurance Playbook. It is written for delivery teams, technical leads, security leads, commercial leads, suppliers and customer stakeholders who need a clear and evidence-based way to plan, build, assure and operate secure services. The intent is to make security repeatable. Security must be visible in contracts, Statements of Work, architecture, backlog items, access decisions, technical controls, assurance evidence and live operations. ### Operating Standard The required operating standard is: * security is built into the work from mobilisation, not added after delivery; * access is granted only on the basis of identity, role, attributes, need, approval and evidence; * data is classified, handled, stored, transmitted and disposed of according to its sensitivity; * technical controls are mapped to risks, requirements and acceptance criteria; * suppliers inherit the controls relevant to the work they perform; * evidence is maintained continuously and is capable of supporting audit, accreditation and customer assurance; * exceptions are time-bound, risk-owned and formally accepted. ### Required Controls | Control | Implementation Standard | Evidence | | ------- | ------------------------------------------------------------------------ | --------------------------------------------------------------------------- | | C01 | Define the control objective before selecting tooling or process. | Policy, design record, approval, log extract, test result or review record. | | C02 | Assign an accountable owner and an operational owner. | Policy, design record, approval, log extract, test result or review record. | | C03 | Document the policy, implementation, evidence and review cadence. | Policy, design record, approval, log extract, test result or review record. | | C04 | Review effectiveness at project gates and live service checkpoints. | Policy, design record, approval, log extract, test result or review record. | | C05 | Record exceptions and residual risk through the risk acceptance process. | Policy, design record, approval, log extract, test result or review record. | ### Delivery Lifecycle Requirements | Lifecycle point | Required security activity | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Opportunity and qualification | Identify customer security constraints, likely classification, vetting needs, regulatory drivers, cyber risk profile, hosting restrictions and accreditation expectations. | | Statement of Work | Define security scope, assumptions, responsibilities, acceptance criteria, evidence requirements, supplier obligations and change control triggers. | | Mobilisation | Appoint security roles, complete onboarding, confirm tooling, create evidence library, open risk register and baseline access model. | | Discovery | Identify assets, users, data, threats, dependencies, existing controls, constraints and assurance route. | | Alpha or design | Perform threat modelling, architecture review, identity model design, data flow review and control mapping. | | Build and test | Apply secure development practices, code review, automated security tests, configuration hardening and evidence capture. | | Release | Verify quality gates, approvals, residual risk, monitoring, rollback, support and incident response readiness. | | Live service | Monitor controls, review access, manage vulnerabilities, test recovery, report metrics and drive continuous improvement. | | Closure or transition | Remove access, archive evidence, dispose of data, confirm supplier exit and record lessons learned. | ### Roles and Accountability | Role | Accountability | | --------------------------- | ------------------------------------------------------------------------------------------- | | Security Lead | Owns the security approach, control mapping, assurance evidence and security risk advice. | | Delivery Lead | Ensures security work is planned, tracked and integrated into delivery governance. | | Technical Lead | Owns architecture, engineering controls, technical remediation and implementation evidence. | | Commercial Lead | Ensures the contract, SoW and supplier terms contain required security obligations. | | Data Owner | Confirms data classification, usage, retention and disposal requirements. | | System Owner | Owns live operational risk, service acceptance and ongoing control effectiveness. | | Supplier Lead | Ensures supplier controls, flow-down obligations and supplier evidence are complete. | | Customer Security Authority | Provides customer-specific policy direction, approvals and risk acceptance where required. | ### Minimum Evidence Pack Maintain evidence that proves the control is designed, implemented, reviewed and operating. The minimum evidence pack should include: * security requirements and assumptions; * risk assessment and risk treatment record; * architecture and data flow diagrams; * identity and access model; * control mapping matrix; * test and assurance evidence; * access approval and review records; * change and release approvals; * incident, vulnerability and exception records; * customer or authority approvals where required. ### Metrics and Reporting Use measurable indicators rather than subjective statements. Suitable metrics include: * percentage of required controls implemented; * number of overdue security actions; * number of open high or critical vulnerabilities; * access review completion rate; * incident response time and recovery time; * number of unapproved exceptions; * supplier evidence completion rate; * percentage of releases passing quality gates first time; * age of residual risks awaiting acceptance. ### Quality Gate Before this area is treated as complete, confirm that: * required controls are implemented or have approved exceptions; * evidence is stored in the agreed location; * owners are named; * review cadence is scheduled; * risks are within tolerance or formally accepted; * supplier obligations are flowed down where applicable; * customer-specific requirements have been checked; * the position is ready for audit or customer assurance review. ### Common Failure Modes Common failures to avoid: * assuming security clearance automatically grants access; * granting access before screening, approval or need-to-know is confirmed; * treating a policy document as evidence of actual control operation; * leaving security requirements out of the SoW; * failing to flow obligations to subcontractors; * relying on manual evidence that cannot be reproduced; * resolving technical issues without updating risk and assurance records; * building in one environment and deploying into another without reassessing controls. ### Checklist * [ ] Requirement defined * [ ] Owner appointed * [ ] Risk assessed * [ ] Controls mapped * [ ] Evidence location confirmed * [ ] Supplier impact checked * [ ] Access model reviewed * [ ] Data handling reviewed * [ ] Quality gate defined * [ ] Exception route confirmed * [ ] Review cadence scheduled # Security Evidence Model ### Purpose This page defines the operating standard for security evidence model within the Security, Vetting and Technical Assurance Playbook. It is written for delivery teams, technical leads, security leads, commercial leads, suppliers and customer stakeholders who need a clear and evidence-based way to plan, build, assure and operate secure services. The intent is to make security repeatable. Security must be visible in contracts, Statements of Work, architecture, backlog items, access decisions, technical controls, assurance evidence and live operations. ### Operating Standard The required operating standard is: * security is built into the work from mobilisation, not added after delivery; * access is granted only on the basis of identity, role, attributes, need, approval and evidence; * data is classified, handled, stored, transmitted and disposed of according to its sensitivity; * technical controls are mapped to risks, requirements and acceptance criteria; * suppliers inherit the controls relevant to the work they perform; * evidence is maintained continuously and is capable of supporting audit, accreditation and customer assurance; * exceptions are time-bound, risk-owned and formally accepted. ### Required Controls | Control | Implementation Standard | Evidence | | ------- | ------------------------------------------------------------------------ | --------------------------------------------------------------------------- | | C01 | Define the control objective before selecting tooling or process. | Policy, design record, approval, log extract, test result or review record. | | C02 | Assign an accountable owner and an operational owner. | Policy, design record, approval, log extract, test result or review record. | | C03 | Document the policy, implementation, evidence and review cadence. | Policy, design record, approval, log extract, test result or review record. | | C04 | Review effectiveness at project gates and live service checkpoints. | Policy, design record, approval, log extract, test result or review record. | | C05 | Record exceptions and residual risk through the risk acceptance process. | Policy, design record, approval, log extract, test result or review record. | ### Delivery Lifecycle Requirements | Lifecycle point | Required security activity | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Opportunity and qualification | Identify customer security constraints, likely classification, vetting needs, regulatory drivers, cyber risk profile, hosting restrictions and accreditation expectations. | | Statement of Work | Define security scope, assumptions, responsibilities, acceptance criteria, evidence requirements, supplier obligations and change control triggers. | | Mobilisation | Appoint security roles, complete onboarding, confirm tooling, create evidence library, open risk register and baseline access model. | | Discovery | Identify assets, users, data, threats, dependencies, existing controls, constraints and assurance route. | | Alpha or design | Perform threat modelling, architecture review, identity model design, data flow review and control mapping. | | Build and test | Apply secure development practices, code review, automated security tests, configuration hardening and evidence capture. | | Release | Verify quality gates, approvals, residual risk, monitoring, rollback, support and incident response readiness. | | Live service | Monitor controls, review access, manage vulnerabilities, test recovery, report metrics and drive continuous improvement. | | Closure or transition | Remove access, archive evidence, dispose of data, confirm supplier exit and record lessons learned. | ### Roles and Accountability | Role | Accountability | | --------------------------- | ------------------------------------------------------------------------------------------- | | Security Lead | Owns the security approach, control mapping, assurance evidence and security risk advice. | | Delivery Lead | Ensures security work is planned, tracked and integrated into delivery governance. | | Technical Lead | Owns architecture, engineering controls, technical remediation and implementation evidence. | | Commercial Lead | Ensures the contract, SoW and supplier terms contain required security obligations. | | Data Owner | Confirms data classification, usage, retention and disposal requirements. | | System Owner | Owns live operational risk, service acceptance and ongoing control effectiveness. | | Supplier Lead | Ensures supplier controls, flow-down obligations and supplier evidence are complete. | | Customer Security Authority | Provides customer-specific policy direction, approvals and risk acceptance where required. | ### Minimum Evidence Pack Maintain evidence that proves the control is designed, implemented, reviewed and operating. The minimum evidence pack should include: * security requirements and assumptions; * risk assessment and risk treatment record; * architecture and data flow diagrams; * identity and access model; * control mapping matrix; * test and assurance evidence; * access approval and review records; * change and release approvals; * incident, vulnerability and exception records; * customer or authority approvals where required. ### Metrics and Reporting Use measurable indicators rather than subjective statements. Suitable metrics include: * percentage of required controls implemented; * number of overdue security actions; * number of open high or critical vulnerabilities; * access review completion rate; * incident response time and recovery time; * number of unapproved exceptions; * supplier evidence completion rate; * percentage of releases passing quality gates first time; * age of residual risks awaiting acceptance. ### Quality Gate Before this area is treated as complete, confirm that: * required controls are implemented or have approved exceptions; * evidence is stored in the agreed location; * owners are named; * review cadence is scheduled; * risks are within tolerance or formally accepted; * supplier obligations are flowed down where applicable; * customer-specific requirements have been checked; * the position is ready for audit or customer assurance review. ### Common Failure Modes Common failures to avoid: * assuming security clearance automatically grants access; * granting access before screening, approval or need-to-know is confirmed; * treating a policy document as evidence of actual control operation; * leaving security requirements out of the SoW; * failing to flow obligations to subcontractors; * relying on manual evidence that cannot be reproduced; * resolving technical issues without updating risk and assurance records; * building in one environment and deploying into another without reassessing controls. ### Checklist * [ ] Requirement defined * [ ] Owner appointed * [ ] Risk assessed * [ ] Controls mapped * [ ] Evidence location confirmed * [ ] Supplier impact checked * [ ] Access model reviewed * [ ] Data handling reviewed * [ ] Quality gate defined * [ ] Exception route confirmed * [ ] Review cadence scheduled # Security Governance and Working Groups ### Purpose This page defines the operating standard for security governance and working groups within the Security, Vetting and Technical Assurance Playbook. It is written for delivery teams, technical leads, security leads, commercial leads, suppliers and customer stakeholders who need a clear and evidence-based way to plan, build, assure and operate secure services. The intent is to make security repeatable. Security must be visible in contracts, Statements of Work, architecture, backlog items, access decisions, technical controls, assurance evidence and live operations. ### Operating Standard The required operating standard is: * security is built into the work from mobilisation, not added after delivery; * access is granted only on the basis of identity, role, attributes, need, approval and evidence; * data is classified, handled, stored, transmitted and disposed of according to its sensitivity; * technical controls are mapped to risks, requirements and acceptance criteria; * suppliers inherit the controls relevant to the work they perform; * evidence is maintained continuously and is capable of supporting audit, accreditation and customer assurance; * exceptions are time-bound, risk-owned and formally accepted. ### Required Controls | Control | Implementation Standard | Evidence | | ------- | ------------------------------------------------------------------------ | --------------------------------------------------------------------------- | | C01 | Define the control objective before selecting tooling or process. | Policy, design record, approval, log extract, test result or review record. | | C02 | Assign an accountable owner and an operational owner. | Policy, design record, approval, log extract, test result or review record. | | C03 | Document the policy, implementation, evidence and review cadence. | Policy, design record, approval, log extract, test result or review record. | | C04 | Review effectiveness at project gates and live service checkpoints. | Policy, design record, approval, log extract, test result or review record. | | C05 | Record exceptions and residual risk through the risk acceptance process. | Policy, design record, approval, log extract, test result or review record. | ### Delivery Lifecycle Requirements | Lifecycle point | Required security activity | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Opportunity and qualification | Identify customer security constraints, likely classification, vetting needs, regulatory drivers, cyber risk profile, hosting restrictions and accreditation expectations. | | Statement of Work | Define security scope, assumptions, responsibilities, acceptance criteria, evidence requirements, supplier obligations and change control triggers. | | Mobilisation | Appoint security roles, complete onboarding, confirm tooling, create evidence library, open risk register and baseline access model. | | Discovery | Identify assets, users, data, threats, dependencies, existing controls, constraints and assurance route. | | Alpha or design | Perform threat modelling, architecture review, identity model design, data flow review and control mapping. | | Build and test | Apply secure development practices, code review, automated security tests, configuration hardening and evidence capture. | | Release | Verify quality gates, approvals, residual risk, monitoring, rollback, support and incident response readiness. | | Live service | Monitor controls, review access, manage vulnerabilities, test recovery, report metrics and drive continuous improvement. | | Closure or transition | Remove access, archive evidence, dispose of data, confirm supplier exit and record lessons learned. | ### Roles and Accountability | Role | Accountability | | --------------------------- | ------------------------------------------------------------------------------------------- | | Security Lead | Owns the security approach, control mapping, assurance evidence and security risk advice. | | Delivery Lead | Ensures security work is planned, tracked and integrated into delivery governance. | | Technical Lead | Owns architecture, engineering controls, technical remediation and implementation evidence. | | Commercial Lead | Ensures the contract, SoW and supplier terms contain required security obligations. | | Data Owner | Confirms data classification, usage, retention and disposal requirements. | | System Owner | Owns live operational risk, service acceptance and ongoing control effectiveness. | | Supplier Lead | Ensures supplier controls, flow-down obligations and supplier evidence are complete. | | Customer Security Authority | Provides customer-specific policy direction, approvals and risk acceptance where required. | ### Minimum Evidence Pack Maintain evidence that proves the control is designed, implemented, reviewed and operating. The minimum evidence pack should include: * security requirements and assumptions; * risk assessment and risk treatment record; * architecture and data flow diagrams; * identity and access model; * control mapping matrix; * test and assurance evidence; * access approval and review records; * change and release approvals; * incident, vulnerability and exception records; * customer or authority approvals where required. ### Metrics and Reporting Use measurable indicators rather than subjective statements. Suitable metrics include: * percentage of required controls implemented; * number of overdue security actions; * number of open high or critical vulnerabilities; * access review completion rate; * incident response time and recovery time; * number of unapproved exceptions; * supplier evidence completion rate; * percentage of releases passing quality gates first time; * age of residual risks awaiting acceptance. ### Quality Gate Before this area is treated as complete, confirm that: * required controls are implemented or have approved exceptions; * evidence is stored in the agreed location; * owners are named; * review cadence is scheduled; * risks are within tolerance or formally accepted; * supplier obligations are flowed down where applicable; * customer-specific requirements have been checked; * the position is ready for audit or customer assurance review. ### Common Failure Modes Common failures to avoid: * assuming security clearance automatically grants access; * granting access before screening, approval or need-to-know is confirmed; * treating a policy document as evidence of actual control operation; * leaving security requirements out of the SoW; * failing to flow obligations to subcontractors; * relying on manual evidence that cannot be reproduced; * resolving technical issues without updating risk and assurance records; * building in one environment and deploying into another without reassessing controls. ### Checklist * [ ] Requirement defined * [ ] Owner appointed * [ ] Risk assessed * [ ] Controls mapped * [ ] Evidence location confirmed * [ ] Supplier impact checked * [ ] Access model reviewed * [ ] Data handling reviewed * [ ] Quality gate defined * [ ] Exception route confirmed * [ ] Review cadence scheduled # Security Mission and Principles ### Purpose This page defines the operating standard for security mission and principles within the Security, Vetting and Technical Assurance Playbook. It is written for delivery teams, technical leads, security leads, commercial leads, suppliers and customer stakeholders who need a clear and evidence-based way to plan, build, assure and operate secure services. The intent is to make security repeatable. Security must be visible in contracts, Statements of Work, architecture, backlog items, access decisions, technical controls, assurance evidence and live operations. ### Operating Standard The required operating standard is: * security is built into the work from mobilisation, not added after delivery; * access is granted only on the basis of identity, role, attributes, need, approval and evidence; * data is classified, handled, stored, transmitted and disposed of according to its sensitivity; * technical controls are mapped to risks, requirements and acceptance criteria; * suppliers inherit the controls relevant to the work they perform; * evidence is maintained continuously and is capable of supporting audit, accreditation and customer assurance; * exceptions are time-bound, risk-owned and formally accepted. ### Required Controls | Control | Implementation Standard | Evidence | | ------- | ------------------------------------------------------------------------ | --------------------------------------------------------------------------- | | C01 | Define the control objective before selecting tooling or process. | Policy, design record, approval, log extract, test result or review record. | | C02 | Assign an accountable owner and an operational owner. | Policy, design record, approval, log extract, test result or review record. | | C03 | Document the policy, implementation, evidence and review cadence. | Policy, design record, approval, log extract, test result or review record. | | C04 | Review effectiveness at project gates and live service checkpoints. | Policy, design record, approval, log extract, test result or review record. | | C05 | Record exceptions and residual risk through the risk acceptance process. | Policy, design record, approval, log extract, test result or review record. | ### Delivery Lifecycle Requirements | Lifecycle point | Required security activity | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Opportunity and qualification | Identify customer security constraints, likely classification, vetting needs, regulatory drivers, cyber risk profile, hosting restrictions and accreditation expectations. | | Statement of Work | Define security scope, assumptions, responsibilities, acceptance criteria, evidence requirements, supplier obligations and change control triggers. | | Mobilisation | Appoint security roles, complete onboarding, confirm tooling, create evidence library, open risk register and baseline access model. | | Discovery | Identify assets, users, data, threats, dependencies, existing controls, constraints and assurance route. | | Alpha or design | Perform threat modelling, architecture review, identity model design, data flow review and control mapping. | | Build and test | Apply secure development practices, code review, automated security tests, configuration hardening and evidence capture. | | Release | Verify quality gates, approvals, residual risk, monitoring, rollback, support and incident response readiness. | | Live service | Monitor controls, review access, manage vulnerabilities, test recovery, report metrics and drive continuous improvement. | | Closure or transition | Remove access, archive evidence, dispose of data, confirm supplier exit and record lessons learned. | ### Roles and Accountability | Role | Accountability | | --------------------------- | ------------------------------------------------------------------------------------------- | | Security Lead | Owns the security approach, control mapping, assurance evidence and security risk advice. | | Delivery Lead | Ensures security work is planned, tracked and integrated into delivery governance. | | Technical Lead | Owns architecture, engineering controls, technical remediation and implementation evidence. | | Commercial Lead | Ensures the contract, SoW and supplier terms contain required security obligations. | | Data Owner | Confirms data classification, usage, retention and disposal requirements. | | System Owner | Owns live operational risk, service acceptance and ongoing control effectiveness. | | Supplier Lead | Ensures supplier controls, flow-down obligations and supplier evidence are complete. | | Customer Security Authority | Provides customer-specific policy direction, approvals and risk acceptance where required. | ### Minimum Evidence Pack Maintain evidence that proves the control is designed, implemented, reviewed and operating. The minimum evidence pack should include: * security requirements and assumptions; * risk assessment and risk treatment record; * architecture and data flow diagrams; * identity and access model; * control mapping matrix; * test and assurance evidence; * access approval and review records; * change and release approvals; * incident, vulnerability and exception records; * customer or authority approvals where required. ### Metrics and Reporting Use measurable indicators rather than subjective statements. Suitable metrics include: * percentage of required controls implemented; * number of overdue security actions; * number of open high or critical vulnerabilities; * access review completion rate; * incident response time and recovery time; * number of unapproved exceptions; * supplier evidence completion rate; * percentage of releases passing quality gates first time; * age of residual risks awaiting acceptance. ### Quality Gate Before this area is treated as complete, confirm that: * required controls are implemented or have approved exceptions; * evidence is stored in the agreed location; * owners are named; * review cadence is scheduled; * risks are within tolerance or formally accepted; * supplier obligations are flowed down where applicable; * customer-specific requirements have been checked; * the position is ready for audit or customer assurance review. ### Common Failure Modes Common failures to avoid: * assuming security clearance automatically grants access; * granting access before screening, approval or need-to-know is confirmed; * treating a policy document as evidence of actual control operation; * leaving security requirements out of the SoW; * failing to flow obligations to subcontractors; * relying on manual evidence that cannot be reproduced; * resolving technical issues without updating risk and assurance records; * building in one environment and deploying into another without reassessing controls. ### Checklist * [ ] Requirement defined * [ ] Owner appointed * [ ] Risk assessed * [ ] Controls mapped * [ ] Evidence location confirmed * [ ] Supplier impact checked * [ ] Access model reviewed * [ ] Data handling reviewed * [ ] Quality gate defined * [ ] Exception route confirmed * [ ] Review cadence scheduled # Security Risk Appetite and Risk Acceptance ### Purpose This page defines the operating standard for security risk appetite and risk acceptance within the Security, Vetting and Technical Assurance Playbook. It is written for delivery teams, technical leads, security leads, commercial leads, suppliers and customer stakeholders who need a clear and evidence-based way to plan, build, assure and operate secure services. The intent is to make security repeatable. Security must be visible in contracts, Statements of Work, architecture, backlog items, access decisions, technical controls, assurance evidence and live operations. ### Operating Standard The required operating standard is: * security is built into the work from mobilisation, not added after delivery; * access is granted only on the basis of identity, role, attributes, need, approval and evidence; * data is classified, handled, stored, transmitted and disposed of according to its sensitivity; * technical controls are mapped to risks, requirements and acceptance criteria; * suppliers inherit the controls relevant to the work they perform; * evidence is maintained continuously and is capable of supporting audit, accreditation and customer assurance; * exceptions are time-bound, risk-owned and formally accepted. ### Required Controls | Control | Implementation Standard | Evidence | | ------- | ------------------------------------------------------------------------ | --------------------------------------------------------------------------- | | C01 | Define the control objective before selecting tooling or process. | Policy, design record, approval, log extract, test result or review record. | | C02 | Assign an accountable owner and an operational owner. | Policy, design record, approval, log extract, test result or review record. | | C03 | Document the policy, implementation, evidence and review cadence. | Policy, design record, approval, log extract, test result or review record. | | C04 | Review effectiveness at project gates and live service checkpoints. | Policy, design record, approval, log extract, test result or review record. | | C05 | Record exceptions and residual risk through the risk acceptance process. | Policy, design record, approval, log extract, test result or review record. | ### Delivery Lifecycle Requirements | Lifecycle point | Required security activity | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Opportunity and qualification | Identify customer security constraints, likely classification, vetting needs, regulatory drivers, cyber risk profile, hosting restrictions and accreditation expectations. | | Statement of Work | Define security scope, assumptions, responsibilities, acceptance criteria, evidence requirements, supplier obligations and change control triggers. | | Mobilisation | Appoint security roles, complete onboarding, confirm tooling, create evidence library, open risk register and baseline access model. | | Discovery | Identify assets, users, data, threats, dependencies, existing controls, constraints and assurance route. | | Alpha or design | Perform threat modelling, architecture review, identity model design, data flow review and control mapping. | | Build and test | Apply secure development practices, code review, automated security tests, configuration hardening and evidence capture. | | Release | Verify quality gates, approvals, residual risk, monitoring, rollback, support and incident response readiness. | | Live service | Monitor controls, review access, manage vulnerabilities, test recovery, report metrics and drive continuous improvement. | | Closure or transition | Remove access, archive evidence, dispose of data, confirm supplier exit and record lessons learned. | ### Roles and Accountability | Role | Accountability | | --------------------------- | ------------------------------------------------------------------------------------------- | | Security Lead | Owns the security approach, control mapping, assurance evidence and security risk advice. | | Delivery Lead | Ensures security work is planned, tracked and integrated into delivery governance. | | Technical Lead | Owns architecture, engineering controls, technical remediation and implementation evidence. | | Commercial Lead | Ensures the contract, SoW and supplier terms contain required security obligations. | | Data Owner | Confirms data classification, usage, retention and disposal requirements. | | System Owner | Owns live operational risk, service acceptance and ongoing control effectiveness. | | Supplier Lead | Ensures supplier controls, flow-down obligations and supplier evidence are complete. | | Customer Security Authority | Provides customer-specific policy direction, approvals and risk acceptance where required. | ### Minimum Evidence Pack Maintain evidence that proves the control is designed, implemented, reviewed and operating. The minimum evidence pack should include: * security requirements and assumptions; * risk assessment and risk treatment record; * architecture and data flow diagrams; * identity and access model; * control mapping matrix; * test and assurance evidence; * access approval and review records; * change and release approvals; * incident, vulnerability and exception records; * customer or authority approvals where required. ### Metrics and Reporting Use measurable indicators rather than subjective statements. Suitable metrics include: * percentage of required controls implemented; * number of overdue security actions; * number of open high or critical vulnerabilities; * access review completion rate; * incident response time and recovery time; * number of unapproved exceptions; * supplier evidence completion rate; * percentage of releases passing quality gates first time; * age of residual risks awaiting acceptance. ### Quality Gate Before this area is treated as complete, confirm that: * required controls are implemented or have approved exceptions; * evidence is stored in the agreed location; * owners are named; * review cadence is scheduled; * risks are within tolerance or formally accepted; * supplier obligations are flowed down where applicable; * customer-specific requirements have been checked; * the position is ready for audit or customer assurance review. ### Common Failure Modes Common failures to avoid: * assuming security clearance automatically grants access; * granting access before screening, approval or need-to-know is confirmed; * treating a policy document as evidence of actual control operation; * leaving security requirements out of the SoW; * failing to flow obligations to subcontractors; * relying on manual evidence that cannot be reproduced; * resolving technical issues without updating risk and assurance records; * building in one environment and deploying into another without reassessing controls. ### Checklist * [ ] Requirement defined * [ ] Owner appointed * [ ] Risk assessed * [ ] Controls mapped * [ ] Evidence location confirmed * [ ] Supplier impact checked * [ ] Access model reviewed * [ ] Data handling reviewed * [ ] Quality gate defined * [ ] Exception route confirmed * [ ] Review cadence scheduled # Secure by Design & Defence Explains how secure-by-design and defence requirements are built into delivery, architecture and control decisions from the start. *** # Defence Cyber Certification Readiness ### Purpose This page defines the operating standard for defence cyber certification readiness within the Security, Vetting and Technical Assurance Playbook. It is written for delivery teams, technical leads, security leads, commercial leads, suppliers and customer stakeholders who need a clear and evidence-based way to plan, build, assure and operate secure services. The intent is to make security repeatable. Security must be visible in contracts, Statements of Work, architecture, backlog items, access decisions, technical controls, assurance evidence and live operations. ### Operating Standard The required operating standard is: * security is built into the work from mobilisation, not added after delivery; * access is granted only on the basis of identity, role, attributes, need, approval and evidence; * data is classified, handled, stored, transmitted and disposed of according to its sensitivity; * technical controls are mapped to risks, requirements and acceptance criteria; * suppliers inherit the controls relevant to the work they perform; * evidence is maintained continuously and is capable of supporting audit, accreditation and customer assurance; * exceptions are time-bound, risk-owned and formally accepted. ### Required Controls | Control | Implementation Standard | Evidence | | ------- | ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | C01 | Define which accreditations or assurance routes are contractually required and which are strategic differentiators. | Policy, design record, approval, log extract, test result or review record. | | C02 | Map each requirement to controls, evidence, owners and review cadence. | Policy, design record, approval, log extract, test result or review record. | | C03 | Maintain a live evidence library rather than building evidence retrospectively. | Policy, design record, approval, log extract, test result or review record. | | C04 | Perform internal readiness reviews before external assessment. | Policy, design record, approval, log extract, test result or review record. | | C05 | Track findings, corrective actions, nonconformities and improvement opportunities. | Policy, design record, approval, log extract, test result or review record. | ### Delivery Lifecycle Requirements | Lifecycle point | Required security activity | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Opportunity and qualification | Identify customer security constraints, likely classification, vetting needs, regulatory drivers, cyber risk profile, hosting restrictions and accreditation expectations. | | Statement of Work | Define security scope, assumptions, responsibilities, acceptance criteria, evidence requirements, supplier obligations and change control triggers. | | Mobilisation | Appoint security roles, complete onboarding, confirm tooling, create evidence library, open risk register and baseline access model. | | Discovery | Identify assets, users, data, threats, dependencies, existing controls, constraints and assurance route. | | Alpha or design | Perform threat modelling, architecture review, identity model design, data flow review and control mapping. | | Build and test | Apply secure development practices, code review, automated security tests, configuration hardening and evidence capture. | | Release | Verify quality gates, approvals, residual risk, monitoring, rollback, support and incident response readiness. | | Live service | Monitor controls, review access, manage vulnerabilities, test recovery, report metrics and drive continuous improvement. | | Closure or transition | Remove access, archive evidence, dispose of data, confirm supplier exit and record lessons learned. | ### Roles and Accountability | Role | Accountability | | --------------------------- | ------------------------------------------------------------------------------------------- | | Security Lead | Owns the security approach, control mapping, assurance evidence and security risk advice. | | Delivery Lead | Ensures security work is planned, tracked and integrated into delivery governance. | | Technical Lead | Owns architecture, engineering controls, technical remediation and implementation evidence. | | Commercial Lead | Ensures the contract, SoW and supplier terms contain required security obligations. | | Data Owner | Confirms data classification, usage, retention and disposal requirements. | | System Owner | Owns live operational risk, service acceptance and ongoing control effectiveness. | | Supplier Lead | Ensures supplier controls, flow-down obligations and supplier evidence are complete. | | Customer Security Authority | Provides customer-specific policy direction, approvals and risk acceptance where required. | ### Minimum Evidence Pack Maintain evidence that proves the control is designed, implemented, reviewed and operating. The minimum evidence pack should include: * security requirements and assumptions; * risk assessment and risk treatment record; * architecture and data flow diagrams; * identity and access model; * control mapping matrix; * test and assurance evidence; * access approval and review records; * change and release approvals; * incident, vulnerability and exception records; * customer or authority approvals where required. ### Metrics and Reporting Use measurable indicators rather than subjective statements. Suitable metrics include: * percentage of required controls implemented; * number of overdue security actions; * number of open high or critical vulnerabilities; * access review completion rate; * incident response time and recovery time; * number of unapproved exceptions; * supplier evidence completion rate; * percentage of releases passing quality gates first time; * age of residual risks awaiting acceptance. ### Quality Gate Before this area is treated as complete, confirm that: * required controls are implemented or have approved exceptions; * evidence is stored in the agreed location; * owners are named; * review cadence is scheduled; * risks are within tolerance or formally accepted; * supplier obligations are flowed down where applicable; * customer-specific requirements have been checked; * the position is ready for audit or customer assurance review. ### Common Failure Modes Common failures to avoid: * assuming security clearance automatically grants access; * granting access before screening, approval or need-to-know is confirmed; * treating a policy document as evidence of actual control operation; * leaving security requirements out of the SoW; * failing to flow obligations to subcontractors; * relying on manual evidence that cannot be reproduced; * resolving technical issues without updating risk and assurance records; * building in one environment and deploying into another without reassessing controls. ### Checklist * [ ] Requirement defined * [ ] Owner appointed * [ ] Risk assessed * [ ] Controls mapped * [ ] Evidence location confirmed * [ ] Supplier impact checked * [ ] Access model reviewed * [ ] Data handling reviewed * [ ] Quality gate defined * [ ] Exception route confirmed * [ ] Review cadence scheduled # JSP 453 Alignment Approach ### Purpose This page defines how we align projects to JSP 453 and related MOD digital, security and assurance expectations without reproducing controlled or sponsor-provided content. ### Operating Position JSP 453 is treated as a project-specific requirement source. The project must obtain the applicable version, chapters, extracts, instructions or policy references through the customer, MOD sponsor or authorised route. The playbook does not assume that public references are complete. It creates a disciplined way to capture, map, implement and evidence compliance. ### Alignment Process 1. Confirm whether the engagement is MOD, defence, defence supplier, defence adjacent, or hosted in a defence environment. 2. Identify the customer security authority, MOD sponsor, accreditor, platform authority and information asset owner. 3. Request the applicable JSP 453 requirements and any related JSPs, security operating procedures or platform standards. 4. Create a JSP 453 alignment register. 5. Map each requirement to architecture, data, identity, hosting, monitoring, operations, supplier and evidence controls. 6. Identify gaps, assumptions and dependencies. 7. Raise deviations through project risk and formal customer approval. 8. Store approvals and implementation evidence in the evidence library. 9. Recheck alignment at design baseline, release, live transition and material change. ### Alignment Register Fields | Field | Description | | ----------------------- | ------------------------------------------------------------------------------------------ | | Requirement ID | Customer or JSP reference. Do not expose controlled text outside approved locations. | | Requirement summary | Short permitted summary. | | Source | MOD sponsor, customer schedule, JSP extract, security instruction or platform requirement. | | Classification | Handling caveat for the requirement and evidence. | | Control owner | Person accountable for implementation. | | Implementation approach | Design or operational control used to meet the requirement. | | Evidence | Document, test, architecture decision, approval or log proving implementation. | | Status | Not started, in progress, implemented, exception requested, accepted, not applicable. | | Residual risk | Risk remaining after control implementation. | | Approval authority | Customer, MOD sponsor, accreditor or internal risk owner. | ### Minimum Controls * confirm hosting model and platform authority; * confirm data classification and handling restrictions; * confirm identity, vetting and access requirements; * confirm audit, monitoring and evidence requirements; * confirm reuse, sustainability and operational support expectations; * confirm whether CSM, Def Stan 05-138, DEFCON 658 or DCC evidence is required; * confirm supplier and subcontractor flow-down obligations. ### Quality Gate No design baseline, production deployment or customer acceptance should proceed until applicable JSP 453 requirements have been reviewed, mapped and either implemented or formally accepted as residual risk. --- [Next Page](https://framework.aic.io/llms-full.txt/1)