# 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 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://framework.aic.io/security-vetting-and-technical-assurance-playbook/security-operating-model/security-mission-and-principles.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.