Security built into how we work. Assurance that keeps getting stronger.
Yeti builds and operates digital products that matter to the organisations that own them. Security is part of how we design, build and run those systems, not a compliance exercise bolted on before launch.
- Multi-factor authentication required
- Named accounts, least privilege
- Review before every merge
- Secrets in vaults, never in code
This page sets out the controls we operate today, and the independent certifications we are working towards.
How Yeti approaches security
We are a product engineering company. The material security considerations in our work usually relate to the access we are trusted with across client code, cloud environments and data. So our controls start there: who has access, how they authenticate, where credentials live, and how changes reach production.
Where an engagement carries additional regulatory or security requirements, those requirements are established as part of architecture and delivery planning rather than added at the end.
The controls already in place
Four areas cover most of what a security review asks us about: who can get in, what they work on, how changes ship, and how client access is kept apart.
Identity, access and credentials
- Multi-factor authentication is required across our key business, engineering and cloud services, including Microsoft and Google, GitHub, Microsoft Azure, AWS, Vercel, Asana and Slack.
- Every team member uses an individual named account. We do not use shared user accounts.
- Company credentials are held in 1Password rather than in documents, spreadsheets or messages.
- Access is granted on least-privilege principles: people are given the access their role and current engagement require.
Company devices
- The team works on company-owned devices.
- Company devices are encrypted and password protected.
- Operating systems and security updates are kept current.
Secure product delivery
- Production code changes are reviewed before merge. Human engineering review is carried out by senior engineering leadership, including our Head of Development where applicable, alongside automated checks in the delivery pipeline.
- Secrets, API keys and credentials are held in vaults and secret stores. They are not committed to source code.
- Environments are separated, and access is separated with them.
- Security requirements are set during architecture and delivery planning. Where a project has specific regulatory, data or access requirements, those are designed in rather than retrofitted.
Client environments and data access
- Access to a client environment is restricted to the people who need it for that engagement.
- Credentials and access are segregated between clients and engagements. One engagement does not carry access to another.
- Access is requested and used for a defined purpose, and we work within the client's own access, approval and change processes where those exist.
- Where a client requires specific access controls, approvals or evidence, we work to their process.
Backup, resilience and vulnerability management
We maintain backup policies covering our integral systems, and carry out restoration testing for those systems annually. Many of the services we rely on are managed platforms with their own durability arrangements; our policies cover the systems that are ours to protect.
We maintain vulnerability and patch-management practices covering company devices, our cloud services and the software we build with. Dependency updates on our own codebases are raised automatically and reviewed.
Cloud and software supply chain
We work primarily in Microsoft Azure and AWS. Cloud permissions follow the same least-privilege and named-account approach as everything else, environments are separated, and configuration is version-controlled where infrastructure as code is in use.
On our own estate, source control is GitHub with review before merge; runtime and dependency versions are pinned and updated through automated, reviewed pull requests. This website itself is a server-rendered marketing site with no database, accounts, uploads or payment processing, published behind a standard set of response security headers.
Our approach to resilient, controlled cloud architecture is described in more detail on our infrastructure page.
Assurance roadmap
We are formalising our assurance posture through independent certification. This is our current roadmap. It describes targets, not achievements.
Cyber Essentials
Target: 30 September 2026
In preparation
The UK government-backed baseline certification covering core technical controls. Preparation is underway. We intend to scope the certification across the relevant Yeti operations where appropriate. Final certification scope will be confirmed with the Certification Body, which has not yet been selected.
Cyber Essentials Plus
Target: 30 November 2026
Planned following Cyber Essentials
Independently tests the same technical controls covered by Cyber Essentials. It is planned once Cyber Essentials is complete. No assessment has been booked.
ISO/IEC 27001:2022
Target: Q2 2027 target window
Planned
Yeti plans to implement an information security management system aligned with ISO/IEC 27001:2022 and pursue certification through a UKAS-accredited certification body. Q2 2027 is our current target window and may change as scope, gap analysis and remediation requirements become known.
Target dates reflect Yeti’s current assurance roadmap and may change as external assessment, scope and remediation requirements become known. Certification will only be described as achieved once independently awarded.
Healthcare assurance
For healthcare engagements, assurance requirements can extend beyond general organisational security into areas such as NHS data-security requirements, clinical safety and product-specific technical assurance. Frameworks such as DSPT, DTAC, DCB0129 and DCB0160 apply according to the product or service being delivered and the role we hold in it, rather than as general company certifications. We assess the applicable requirements for each engagement as part of our healthcare-readiness work.
Continuous improvement
Our assurance programme is active. We review and strengthen our controls as it develops, and we will describe an independent certification as achieved only once it has actually been awarded. This page is dated so you can see how current it is.
Need to assess Yeti?
If you are assessing Yeti as a supplier, we are happy to work through your security and procurement requirements with the relevant Yeti team, including security questionnaires, architecture and data-flow information for the work in question, and details of the controls described on this page.
Our privacy notice sets out how we handle personal information, including retention and the service providers involved.
Reporting a security concern
If you believe you have found a security vulnerability affecting this website or a Yeti Digital Ltd product, please tell us. Email Email our security team. Please include enough detail for us to reproduce the issue: the affected URL or component, the behaviour you observed and the steps you took.
Reports are read in English. Machine-readable contact details are published at /.well-known/security.txt.
Please do not include
- Passwords, access credentials or authentication tokens.
- Payment-card information.
- Personal data belonging to other people beyond what is strictly necessary to describe the issue.
Scope
This page covers the yetiinc.com website and products operated by Yeti Digital Ltd. Issues affecting a client’s own systems should be reported to that client.
This page is not an invitation to test, scan or attempt to access systems or data, and it does not grant permission to do so. It does not offer a reward, and it does not set out a response time or any other commitment.
Other enquiries
For anything that is not a security report, use Email us.
Security information last reviewed: 20 August 2026.