Purpose of this page
This is the working list of the engineering standards, security controls, and regulatory frameworks that Byte Bridges Solutions Ltd builds to on every project. Each entry names a specific framework, the control or principle implemented, and the type of evidence we can produce on request. It exists so that procurement teams, security reviewers, and clients with their own audit obligations can see — concretely — what they are buying into.
What this page is not. This is not a list of certifications we hold. Where Byte Bridges is certified or listed, that is stated explicitly with the certification body and reference number. Everything on this page is engineering practice, evidenced through delivery — not external attestation.
Every entry on the rest of the site that names a framework links back to this page, by policy. If you spot a framework named elsewhere on the site that does not appear here or in the “What we don’t claim” section below, please tell us — we’d rather correct it than defend it.
How to read each entry
- Framework / standard — full name and version
- Status — Implemented (active in current delivery), In flight (rolling out), On request (we’ll add it for projects that need it), or Implemented when relevant (applied where the project context calls for it)
- What we implement — specific control IDs or principles, not vague summaries
- Evidence we can produce — the artefact we’d hand to your auditor or security reviewer
- Scope — where this control applies in our delivery (and where it doesn’t)
Controls at a glance
| Area | Framework / Control | Scope | Status |
|---|---|---|---|
| 1. Application Security | OWASP Application Security Verification Standard (ASVS) v4.0.3 | All client-facing applications. Internal tooling held to ASVS Level 1 minimum. | Implemented |
| OWASP Top 10 (2021) | Every project, every PR. | Implemented | |
| OWASP API Security Top 10 (2023) | All API endpoints. | Implemented | |
| OWASP Mobile Application Security Verification Standard (MASVS) v2.0 | React Native deliveries only. | Implemented | |
| Penetration testing | Every build we deliver, before launch. | Implemented | |
| 2. Information Security Architecture | ISO/IEC 27002:2022 — Information security controls | Engagements with explicit information-security obligations. Lighter version applied to all engagements. | Implemented |
| NIST Cybersecurity Framework v2.0 | All engagements with security obligations. | Implemented | |
| CIS Controls v8 (Implementation Group 1) | Cloud infrastructure delivered or managed by Byte Bridges. | Implemented | |
| CIS Benchmarks (AWS Foundations v1.5, Docker v1.7) | AWS-hosted projects, containerised deployments. | Implemented | |
| AICPA Trust Services Criteria (TSC 2017, with 2022 revisions) | Engagements where the client is themselves pursuing an attestation and needs supplier evidence. | On request | |
| NIST SP 800-53 Rev 5 (selected control families) | Engagements with US compliance overlap, or where the client requires this mapping. | On request | |
| 3. Privacy & Data Protection | UK GDPR (Data Protection Act 2018) | Every project handling personal data. | Implemented |
| ICO Age-Appropriate Design Code (Children's Code) | Education, consumer-facing, or any service likely-accessed-by-children. | Implemented when relevant | |
| PECR (Privacy and Electronic Communications Regulations 2003, as amended) | Every UK-facing site we ship. | Implemented | |
| NIS Regulations 2018 (UK transposition of NIS Directive) | Suppliers to OES / RDSPs only — flagged in scoping. | On request | |
| Payment processing — Byte Bridges as integrator | Every payment-handling project. | Implemented | |
| 4. Accessibility | Web Content Accessibility Guidelines (WCAG) 2.1 Level AA | All web deliveries. | Implemented |
| Web Content Accessibility Guidelines (WCAG) 2.2 Level AA | New projects from launch onward; existing projects on next major release. | In flight | |
| WAI-ARIA 1.2 | All web deliveries. | Implemented | |
| Equality Act 2010 (UK) | Every UK-facing project. | Implemented | |
| GDS Service Manual | Public sector engagements only. | Implemented when relevant | |
| Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 | Public sector engagements. | Implemented when relevant |
1. Application Security
OWASP Application Security Verification Standard (ASVS) v4.0.3
Implemented- What we implement
- ASVS Level 2 across all production code — V1 (Architecture), V2 (Authentication), V3 (Session Management), V4 (Access Control), V5 (Validation, Sanitisation & Encoding), V7 (Error Handling & Logging), V8 (Data Protection), V9 (Communications), V10 (Malicious Code), V13 (API & Web Service).
- Evidence we can produce
- Code review checklist, type checks, linting and the automated test suite before every release, dependency vulnerability scanning, per-feature threat model.
- Scope
- All client-facing applications. Internal tooling held to ASVS Level 1 minimum.
OWASP Top 10 (2021)
Implemented- What we implement
- All ten categories — A01:2021 Broken Access Control through A10:2021 Server-Side Request Forgery. Specific mitigations per category documented per project.
- Evidence we can produce
- Pre-PR checklist, dependency vulnerability scanning, threat model docs.
- Scope
- Every project, every PR.
OWASP API Security Top 10 (2023)
Implemented- What we implement
- All ten — API1:2023 Broken Object Level Authorization through API10:2023 Unsafe Consumption of APIs.
- Evidence we can produce
- API design review, per-endpoint authorisation tests, route analysis.
- Scope
- All API endpoints.
OWASP Mobile Application Security Verification Standard (MASVS) v2.0
Implemented- What we implement
- MASVS-STORAGE, MASVS-CRYPTO, MASVS-AUTH, MASVS-NETWORK, MASVS-PLATFORM, MASVS-CODE, MASVS-RESILIENCE.
- Evidence we can produce
- Mobile-specific security review, certificate pinning config, biometric auth integration.
- Scope
- React Native deliveries only.
Penetration testing
Implemented- What we implement
- We penetration-test what we build before launch, in house. We are not an accredited testing firm; an independent test can be arranged.
- Evidence we can produce
- Test notes and findings for each release, shared with the client on request.
- Scope
- Every build we deliver, before launch.
2. Information Security Architecture
ISO/IEC 27002:2022 — Information security controls
Implemented- What we implement
- Controls drawn from clauses 5 (Organisational), 6 (People), 7 (Physical), and 8 (Technological). Mapping document maintained per project.
- Evidence we can produce
- Per-project controls register; mapping spreadsheet available on request.
- Scope
- Engagements with explicit information-security obligations. Lighter version applied to all engagements.
- Wording note
- We build to ISO 27002 controls. We do not hold ISO 27001 certification. If your procurement requires a certified supplier, this is not us yet — though our control documentation is structured to support your own audit and is shareable.
NIST Cybersecurity Framework v2.0
Implemented- What we implement
- Govern, Identify, Protect, Detect, Respond, Recover — mapped per project to specific subcategories.
- Evidence we can produce
- CSF mapping document, incident response runbook template.
- Scope
- All engagements with security obligations.
CIS Controls v8 (Implementation Group 1)
Implemented- What we implement
- All 56 IG1 safeguards across the 18 CIS Controls.
- Evidence we can produce
- Per-environment hardening checklist, IaC modules (Terraform / CDK).
- Scope
- Cloud infrastructure delivered or managed by Byte Bridges.
CIS Benchmarks (AWS Foundations v1.5, Docker v1.7)
Implemented- What we implement
- Level 1 baseline; Level 2 on request.
- Evidence we can produce
- Compliance scan output (Prowler for AWS, Docker bench).
- Scope
- AWS-hosted projects, containerised deployments.
AICPA Trust Services Criteria (TSC 2017, with 2022 revisions)
On request- What we implement
- Security (CC1–CC9), Availability (A1), Confidentiality (C1) — core criteria mapped to delivery practice.
- Evidence we can produce
- Controls mapping document.
- Scope
- Engagements where the client is themselves pursuing an attestation and needs supplier evidence.
- Wording note
- We map to the AICPA Trust Services Criteria. We do not hold an attestation against them. Mapping the criteria is engineering practice; the attestation is a CPA-issued report against those criteria. Different things.
NIST SP 800-53 Rev 5 (selected control families)
On request- What we implement
- AU (Audit & Accountability), AC (Access Control), CM (Configuration Management), IA (Identification & Authentication), SC (System & Communications Protection), SI (System & Information Integrity) — at moderate baseline.
- Evidence we can produce
- Control mapping per project.
- Scope
- Engagements with US compliance overlap, or where the client requires this mapping.
3. Privacy & Data Protection
UK GDPR (Data Protection Act 2018)
Implemented- What we implement
- Article 25 — Data protection by design and by default. Article 32 — Security of processing. Article 30 — Records of processing activities (where Byte Bridges is processor).
- Evidence we can produce
- Data Protection Impact Assessment template, Records of Processing template, processor contract clauses.
- Scope
- Every project handling personal data.
ICO Age-Appropriate Design Code (Children's Code)
Implemented when relevant- What we implement
- All 15 standards where the project is likely to be accessed by children.
- Evidence we can produce
- Children's Code applicability assessment, age-appropriate defaults documented.
- Scope
- Education, consumer-facing, or any service likely-accessed-by-children.
PECR (Privacy and Electronic Communications Regulations 2003, as amended)
Implemented- What we implement
- Cookie consent (Regulation 6), email marketing consent (Regulation 22), service messages (Regulation 23).
- Evidence we can produce
- Cookie consent banner implementation, ESP setup documentation.
- Scope
- Every UK-facing site we ship.
NIS Regulations 2018 (UK transposition of NIS Directive)
On request- What we implement
- Awareness of obligations where the client is a Relevant Digital Service Provider or supplier to one. Applicability assessment at discovery.
- Evidence we can produce
- Applicability assessment documented at discovery.
- Scope
- Suppliers to OES / RDSPs only — flagged in scoping.
Payment processing — Byte Bridges as integrator
Implemented- What we implement
- Payment flows offloaded to validated providers (Stripe, Square, GoCardless). Cardholder data does not transit Byte Bridges-built systems.
- Evidence we can produce
- Payment integration architecture diagram showing data flow.
- Scope
- Every payment-handling project.
- Wording note
- Because cardholder data is handled by the validated provider, our delivery is out of scope at the application layer (SAQ A pattern). We do not represent ourselves as a card-handling certified entity, because the question does not apply at our layer of the stack.
4. Accessibility
Web Content Accessibility Guidelines (WCAG) 2.1 Level AA
Implemented- What we implement
- All 50 Level AA success criteria across the four principles (Perceivable, Operable, Understandable, Robust).
- Evidence we can produce
- axe-core CI integration, manual keyboard audit per release, screen reader spot-checks (NVDA / VoiceOver).
- Scope
- All web deliveries.
Web Content Accessibility Guidelines (WCAG) 2.2 Level AA
In flight- What we implement
- The 2.2 success criteria — 2.4.11 Focus Not Obscured (Minimum), 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance, 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.3.7 Redundant Entry, 3.3.8 Accessible Authentication (Minimum).
- Evidence we can produce
- WCAG 2.2 audit output, fix log.
- Scope
- New projects from launch onward; existing projects on next major release.
- Wording note
- Our public commitment is WCAG 2.1 AA today, working towards 2.2 AA. Marketing copy reflects 2.1 AA until the 2.2 audit is complete.
WAI-ARIA 1.2
Implemented- What we implement
- Authoring practices for all interactive components — landmarks, live regions, dialogs, menus, etc.
- Evidence we can produce
- Component library accessibility tests.
- Scope
- All web deliveries.
Equality Act 2010 (UK)
Implemented- What we implement
- Reasonable adjustments framing applied to all public-facing UI.
- Evidence we can produce
- Accessibility statement published per service.
- Scope
- Every UK-facing project.
GDS Service Manual
Implemented when relevant- What we implement
- Where the project is or will be a public-facing government service. Specific guidance: agile delivery, accessibility, technology code of practice, performance metrics.
- Evidence we can produce
- Service-specific assessment against the manual.
- Scope
- Public sector engagements only.
Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018
Implemented when relevant- What we implement
- Production of accessibility statements to the prescribed structure where the client is a public sector body.
- Evidence we can produce
- Accessibility statement drafted per service.
- Scope
- Public sector engagements.
What we don’t claim — and why
This section exists deliberately. It pre-empts the questions a discerning buyer would otherwise ask on a discovery call. Each entry names a certification, attestation, or scheme that Byte Bridges does not hold or qualify for, with the reason stated plainly.
Cyber Essentials / Cyber Essentials Plus certification
We are not currently certified by IASME or another accreditation body. We implement controls consistent with the Cyber Essentials baseline; certification is a separate step we may pursue.
ISO 27001 certification
We do not hold an external ISO 27001 audit. Our delivery maps to ISO 27002 controls; the audit is the missing piece.
ISO 9001 certification
We are not certified to ISO 9001 (Quality Management Systems).
SOC 2 attestation (Type 1 or Type 2)
We have no AICPA-affiliated CPA report. We can map to the Trust Services Criteria for clients whose own audit process needs supplier evidence.
PCI-DSS certification (any merchant or service-provider tier)
We are not a payment processor. Cardholder data handling is offloaded to validated providers (Stripe, Square, GoCardless).
NHS Data Security and Protection Toolkit completion
We have not completed the toolkit as an organisation. Where a project handles NHS data, completion is project-scoped and assessed at discovery.
NCSC Cyber Assessment Framework
CAF is an assessment framework for Operators of Essential Services and Critical National Infrastructure suppliers. We are neither at present.
G-Cloud Digital Marketplace listing
We are not currently listed on G-Cloud.
FCA authorisation
We are not an FCA-authorised firm. We can build for FCA-authorised clients; we are not one.
MHRA registration
We do not deliver medical devices. Software-as-a-medical-device work would require explicit scoping and registration before any engagement.
WCAG 2.2 AA conformance today
Our published statement is WCAG 2.1 AA. The 2.2 criteria are in flight (see Accessibility section). Marketing copy reflects 2.1 AA — working towards 2.2.
For procurement teams
If you are evaluating Byte Bridges as a supplier and your security review needs more than this page provides, the following are available on request, under NDA where appropriate:
- Per-control mapping spreadsheets (ISO 27002, NIST CSF, AICPA TSC)
- Specific CI workflow extracts demonstrating implementation
- Architecture diagrams with security annotations
- Sample DPIAs and ROPA entries (anonymised)
- Sample threat models (anonymised)
- Incident response runbook template
- Disaster recovery runbook template
- Supplier review questionnaire — pre-filled answers
Contact: hello@bytebridges.co.uk with subject line “Controls Map — procurement review”. We aim to respond within 24 hours on working days.
Maintenance commitment
This page is reviewed at least quarterly and updated whenever:
- A new framework or standard is added to delivery practice
- An existing control’s status changes (e.g., a control moves from On request to Implemented)
- A certification is achieved — in which case the certification reference replaces the corresponding “we build to” entry
- A control is removed because it is no longer current practice