External Supplier Requirements
External Supplier Requirements
Purpose and Context
The Ministry of Justice engages with a diverse range of external suppliers across technology, delivery, and integration services. However, supplier-delivered systems and code have historically operated under varying standards for security, governance, and operational practices. This inconsistency creates risk across MOJ digital infrastructure, increases audit and compliance burdens, and hampers interoperability.
This document establishes a clear, non-negotiable baseline of digital delivery, security, and technology requirements that all suppliers must meet. By doing so, we achieve:
- Consistent security and governance standards across all supplier-delivered services and code
- Reduced risk through mandatory compliance with MOJ security controls and architectural patterns
- Improved auditability and accountability by establishing clear ownership and forensic readiness expectations
- Faster, more cost-effective delivery by embedding standards upfront rather than remediating after delivery
- Alignment with UK Government standards, including the Technology Code of Practice and GDS guidance
These requirements apply equally to all suppliers—whether they are strategic partners, specialist firms, or single-point service providers. They must be met regardless of contract value, engagement duration, or supplier tier.
This document aligns with:
- UK Government Technology Code of Practice (especially on security, interoperability, and open standards)
- GDS Service Standard and associated guidance on security and technology practices
- MOJ's strategic commitment to coherent, secure, and operationally excellent digital services
- NCSC and Cabinet Office Secure by Design principles
- Existing MOJ technical and cyber security guidance across all teams and delivery partners
Code, repositories and developer tooling
1. You must use the Ministry of Justice GitHub organisation for all MOJ code
All code produced for the MOJ, including application code, infrastructure code and configuration, must be stored within the single MOJ GitHub organisation. The use of external GitHub organisations, personal accounts, GitLab, Bitbucket or any other platform for MOJ code is not permitted.
See also: MOJ Open IT Policy
2. You must comply with MOJ GitHub security baselines
All repositories must comply with centrally mandated GitHub security controls, including branch protection, restricted GITHUB_TOKEN permissions and organisation-level enforcement. Workflows must operate on a least-privilege basis by default.
See also: UK Government Secure by Design guidance, MOJ Security Guidance
3. You must not introduce third party developer tools without explicit approval
The use of third-party tools, IDE extensions, GitHub Actions or CI/CD integrations is restricted. Any such tooling must be subject to explicit approval and appropriate governance, including version pinning where required to manage supply-chain risk.
See also: MOJ Open IT Policy, GitHub Actions Security Guidelines
4. You must enable and use mandated automated security scanning
Repositories must use MOJ-mandated automated security tooling, including code scanning, secret scanning and dependency review through centrally managed DevSecOps pipelines.
See also: MOJ Forensic Readiness Standard, MOJ Cyber Strategy
Ownership, accountability and auditability
5. You must assign clear, named ownership for all repositories and services
Each repository must have clearly identified and contactable owners. Accountability for code and services must not be delegated solely to suppliers. No exception shall apply to this ownership requirement.
See also: MOJ Open IT Policy
6. You must operate in a way that supports forensic investigation
Systems and services delivered by suppliers must meet MOJ forensic readiness requirements, including audit logging, evidence preservation and support for legally admissible investigation activity.
See also: MOJ Security Guidance
Data handling and information security
7. You must comply with MOJ information classification and handling rules
All information handled by suppliers must be managed in accordance with MOJ classification and handling policies. This requirement applies to code, logs, test data, documentation and support tooling.
See also: MOJ Security Guidance
8. You must not store secrets in code or repositories
Secrets, credentials and tokens must not be committed to repositories. Where such material is detected, remediation shall be mandatory. Secret scanning shall be enforced across public, internal and private repositories.
See also: MOJ Cyber Strategy
9. You must not use unauthorised AI or data processing tools
MOJ data must not be shared with non-approved AI tools or consumer services. Any use of AI must comply with MOJ controls relating to third-party assurance, data protection and supply-chain risk.
See also: MOJ Security Guidance
10. You must comply with MOJ data protection and sovereignty guidance
Suppliers must ensure that appropriate safeguards are in place for personal and official data, including the completion of DPIAs where required. The MOJ does not mandate UK-only hosting by default, but does require demonstrable compliance with applicable data protection obligations.
See also: MOJ Security Guidance
Secure by design and supply chain risk
11. You must follow Secure by Design principles
All digital services, tooling and integrations must align with UK government Secure by Design expectations, including the early and continuous management of third-party product security risks.
See also: UK Government Secure by Design guidance
12. You must expect continuous assurance, not point in time sign off
Supplier services and tools must support ongoing security assessment throughout their lifecycle and must not rely solely on onboarding or contract commencement controls.
See also: UK Government Secure by Design guidance
Technology choices and standards (Tech Radar)
13. You must align technology choices with the MOJ Tech Radar
All technology choices made by suppliers in the delivery of digital work for the MOJ must align with the MOJ Tech Radar, which establishes the expected position on tools, platforms, languages, frameworks and techniques across MOJ teams.
See also: MOJ Tech Radar
14. You must not introduce technologies discouraged by the MOJ Tech Radar
Where the Tech Radar identifies technologies as not recommended, replacement-only or candidates for retirement, suppliers must not introduce such technologies into new services or solutions.
See also: MOJ Tech Radar
15. You must treat the Tech Radar as a constraint, not a suggestion
The MOJ Tech Radar constitutes a governance mechanism. Suppliers must design within its constraints and must escalate at an early stage where an exception may be required, rather than diverging by default.
See also: MOJ Tech Radar
16. You must engage openly on technology decisions
The Tech Radar is maintained in the open and informed by community discussion. Suppliers are expected to collaborate transparently with MOJ teams on technology decisions and must not introduce unnecessary divergence at a late stage.
See also: MOJ Tech Radar
Foundational platforms and common capabilities
17. You must use MOJ foundational platforms by default
Suppliers must deliver services using MOJ foundational platforms and shared capabilities where they exist and are suitable for the service need. New parallel platforms, duplicate hosting stacks, or overlapping shared services must not be introduced without formal architectural approval.
This includes, where applicable, use of approved MOJ capabilities for hosting, identity and access, observability, CI/CD, and operational tooling. Examples include the Cloud Platform, Modernisation Platform, and centrally managed identity and CI/CD services. These examples are illustrative and non-exhaustive; suppliers must use all applicable current and future MOJ foundational platforms as directed.
See also: MOJ Tech Radar, MOJ Security Guidance
18. You must obtain approval before diverging from foundational platforms
Any deviation from approved foundational platforms must be raised early through MOJ governance channels with a written rationale, risk assessment, and time-bounded remediation or exit plan.
Suppliers must not treat exceptions as permanent design choices by default and must support migration back to approved platforms when directed. This applies equally to existing and newly introduced foundational capabilities.
Quality assurance and testing
19. You must implement continuous integration and automated testing
All code must be tested through a managed CI/CD pipeline before deployment to any environment. This includes automated unit tests, integration tests, and security scanning as part of the standard build process. Test failures must block deployment.
Quality gates must be enforced at each stage:
- Build stage: Code compilation, linting, and static analysis
- Test stage: Automated functional and integration test execution with minimum coverage targets
- Security stage: SAST (Static Application Security Testing), dependency scanning, and secret detection
- Deployment stage: Automated deployment to non-production and production environments with approval controls
Suppliers must provide visibility into test results, coverage metrics, and pipeline status to MOJ teams.
See also: UK Government Technology Code of Practice – Defining user needs
20. You must document test coverage and quality metrics
Suppliers must maintain and report on test coverage, quality metrics, and defect trends. A minimum unit test coverage target of 70% is expected for new code; higher coverage is required for critical paths.
Test and quality documentation must be maintained in line with code repositories and versioned accordingly.
Accessibility and inclusive design
21. You must comply with accessibility standards (WCAG 2.1 Level AA)
All digital services and user-facing applications delivered by suppliers must comply with Web Content Accessibility Guidelines (WCAG) 2.1 Level AA as a minimum, or EN 301 549 for non-web applications.
This requirement applies to:
- Web applications and interfaces
- Mobile applications (iOS and Android)
- Documents (PDFs, Word, spreadsheets)
- Video content (captions and audio descriptions)
- APIs and integration interfaces (machine-readable accessibility where applicable)
Accessibility compliance must be verified through both automated testing and manual accessibility audits before production release.
See also: UK Government Equality Act 2010 guidance, WCAG 2.1 Guidelines, GDS Accessibility Requirements
22. You must treat accessibility as a continuous discipline, not a retrospective fix
Accessibility must be designed in from the start, not retrofitted at the end of development. Suppliers must:
- Include accessibility requirements in user stories and acceptance criteria
- Conduct accessibility testing at each sprint or iteration
- Train development teams on accessible design principles and practices
- Include accessibility checks in code review processes
- Remediate accessibility defects with the same priority as security bugs
Accessibility testing must include testing with people using assistive technologies and real accessibility audits, not just automated scanning.
Ways of working with MOJ Digital
23. You must work in the open by default
The MOJ works in the open wherever information is not classified above OFFICIAL and does not contain personal data. Suppliers are expected to collaborate openly using MOJ-approved tools, repositories and delivery practices.
See also: MOJ Digital Strategy 2025
24. You must follow MOJ technical and security guidance
All technical decisions taken by suppliers must align with published MOJ technical and cyber security guidance, which applies equally to staff, contractors and suppliers.
See also: MOJ Security Guidance
Was this page useful?