Trust & Security
The digital partner your security and procurement teams can review
Choosing a digital agency means giving an outside company access to parts of your business — website administration, customer information, source code, brand assets, analytics, credentials, ecommerce systems, internal workflows, AI systems and business data.
That access creates responsibility on both sides. 10turtle's Trust & Security framework is designed to make that responsibility visible. We document how we protect the information you share with us and how we approach security, accessibility, privacy, payments, AI and migrations in the systems we build. The goal is straightforward: make vendor security easier to review before the project starts.
Vendor security reviewSecurity at a glance
Review-ready- ISO/IEC 27001Information security management ISMS
- SOC 2Controls relevant to service organizations Controls
- WCAG 2.1–2.2 AAAccessibility built into delivery Built in
- GDPR & CCPAPrivacy and data-protection readiness Ready
- PCI DSS 4.0.1Payment security for ecommerce Ready
Make vendor security easier to review before the project starts.
TRUSTED BY TEAMS THAT SHIP
Click any platform to read verified customer reviews.
Security at a glance
Our security and compliance approach
Our security and compliance approach includes consideration of frameworks, controls and engineering practices. The exact requirements and applicability depend on the project, data, systems and jurisdiction. For procurement and security reviews, supporting documentation can be provided where applicable.
- ISO/IEC 27001 & SOC 2, information security management and controls relevant to service organizations
- Least-privilege access, access limited to the people who actually need it for their responsibilities
- Encryption & credential protection, in transit and at rest where applicable; managed secret-handling practices
- GDPR, CCPA & incident response, privacy readiness, DPAs where applicable, and a defined response process
- Secure software development & WCAG 2.1–2.2 AA, security throughout development; accessibility built into delivery
- PCI DSS 4.0.1 & AI data governance, payment architectures that reduce exposure; scoped AI access and documented data flows
For procurement and security reviews, we can provide a security pack, DPA and security-questionnaire support for reviewers who need deeper documentation.
Two Security Questions. One Trust Framework.
When evaluating a digital agency, there are two different questions to answer
These are different security questions. We address both.
1 Working with you
How does the agency protect my information?
This covers the information you give us during the engagement: credentials, customer records, source code, designs, contracts, business information and personal information.
Least privilegeEncryptionSecure credentialsNDAs & IPIncident response
See how we protect your data 2 What we buildHow will the agency secure what it builds?
This covers the systems we deliver: websites, ecommerce stores, applications, automations, AI systems and integrations.
Secure by designAccessibilityPayment securityPrivacyAI governance
See how we build securely If your procurement or security team is evaluating 10turtle, the review can cover internal security — how we protect your information — and engineering security — how we build what we deliver.
Why agency security matters
Your digital agency can become part of your organization's security perimeter
An agency may have access to CMS administration, hosting, ecommerce platforms, customer databases, analytics, payment integrations, source repositories, cloud services, API credentials and AI platforms.
A security failure at a third-party provider can therefore affect the businesses that provider serves. That is why vendor due diligence matters. A procurement or security team should be able to ask: Who has access? How is access controlled? How is data protected? What happens if something goes wrong? How is the delivered software secured? What documentation can the agency provide?
Our Trust & Security approach is designed to answer those questions before they become blockers.
Your businessdata · logins · IP
Your agencynow inside your perimeter
2kinds of security every serious buyer should ask about: how we protect your information, and how we secure what we build.
How We Protect Your DataLeast-privilege access, encryption, credentials, NDAs, incident response and people security
Concept: an audit or certificate close-up
IMG 01 · CERTS · cover2standards buyers often ask about: ISO/IEC 27001 and SOC 2.
Security standards and frameworks
ISO/IEC 27001 and SOC 2 are not identical
Which framework a buyer requires depends on their organization, industry, geography, procurement process and contractual requirements. We do not treat one certification or framework as a universal substitute for security. Where a specific certification, report or formal attestation is required, the applicable evidence can be reviewed as part of vendor due diligence.
ISO/IEC 27001
International standardISO/IEC 27001 is an international standard for information security management systems. It focuses on how an organization manages information-security risk through a formal management system. It is broader than simply securing a website. It can cover risk management, access control, policies, incident management, business continuity and information security processes. The important distinction is that ISO/IEC 27001 concerns the management system. Project-specific engineering still matters.
Owner verification: Certificate number, accredited issuing body, certified scope and expiry are currently marked for owner verification. Those details should be confirmed through the security pack before being used in contractual or marketing claims.
SOC 2
Security controlsSOC 2 is a framework used to evaluate controls relevant to service organizations. It is particularly common in US enterprise procurement. SOC 2 reports can address security, availability, processing integrity, confidentiality and privacy. Type I and Type II reports serve different purposes. If a prospective client requires SOC 2 evidence, the appropriate report and scope should be confirmed during procurement.
Owner verification: Exact Type I/II status is currently marked for confirmation. Prospective clients requiring SOC 2 evidence should request the applicable report or supporting documentation through the security-review path.
Which framework does your project need?
Which one a buyer requires depends on their organization, industry, geography, procurement process and contractual requirements. A UAE project may involve different requirements from a project serving customers in Europe, North America or other markets.
Ask us about SOC 2 — particularly common in US enterprise procurement.
Type I and Type II reports serve different purposes. If your procurement process requires a specific report or evidence set, tell us during discovery so the appropriate review can be discussed.
SOC 2Security controlsProcurement review
Confirm UAE and international requirements during discovery.
ISO/IEC 27001 is commonly used for vendor security and information-security assurance internationally. For projects involving UAE data protection, privacy or sector-specific obligations, the applicable requirements should be confirmed during discovery.
UAE data protectionISO/IEC 27001Project-specific
Security should follow the project, not a generic checklist.
These frameworks are not identical. ISO/IEC 27001 focuses on a structured information security management system; SOC 2 focuses on evidence of relevant controls. Which one you need depends on your organization, industry, geography and contractual requirements.
IndustryGeographyData & systems
| Criterion | ISO/IEC 27001 | SOC 2 |
|---|---|---|
| Primary focus | Information security management system | Controls and their operation |
| Common market | International | Particularly common in US enterprise procurement |
| Format | Certification | Type I or Type II report |
| Core purpose | Structured security management | Evidence of relevant controls |
| Buyer use | Vendor security and information-security assurance | Enterprise vendor due diligence |
| Best when your buyer is | Seeking international ISMS assurance | A US enterprise procurement team |
Where a specific certification, report or formal attestation is required, the applicable evidence can be reviewed as part of vendor due diligence. Request the Security Pack to start that conversation.
Concept: secure handling of credentials and data
IMG 02 · DATA · coverWorking with 10turtle
How we protect your data
Access should be limited to the people who actually need it. Technology is only part of security — people interact with client accounts, credentials, source code, customer information and internal systems.
Least-Privilege Access
We apply role-based access principles so team members receive the access required for their responsibilities rather than unrestricted access by default. When access is no longer required, it should be removed.
Encryption
Our security approach includes encryption in transit and at rest where applicable. This reduces exposure if information is intercepted or storage infrastructure is compromised. The exact technical implementation depends on the systems involved in the project.
Secure Credential Handling
Passwords, API keys, access tokens and other secrets should not be casually stored in documents, email threads or chat messages. Our approach uses managed credential and secret-handling practices rather than treating sensitive credentials as ordinary project information.
NDAs and Intellectual Property
Depending on the engagement, this can include non-disclosure agreements, data-processing agreements, clear IP ownership, source-code ownership and confidential project information. The objective is to make ownership and confidentiality clear before sensitive work begins.
Incident Response
Our security framework includes an incident-response process covering identification, containment, investigation, remediation and communication. Where an incident affects client information, appropriate notification and remediation processes apply. Specific timelines depend on the contract, data, jurisdiction and applicable requirements.
Subprocessor and Vendor Considerations
Digital projects often depend on hosting, cloud services, analytics, SaaS platforms, payment providers, AI model providers and development tools. We consider relevant subprocessors and technology providers involved in a project and can provide appropriate information through the security-review process.
People Security
Our approach includes security awareness and appropriate onboarding practices for team members who handle client work. The goal is to reduce the risk created by the human layer of a digital project.
Depending on the engagement and review requirements, documentation may include a security overview, information-security documentation, DPA, NDA, security questionnaire, certification evidence, subprocessor information, secure-development information, data-flow information and relevant testing evidence. Some information may require NDA or controlled disclosure.
Need information for procurement? 10turtle can provide relevant security documentation and supporting evidence through the appropriate review process — including a security pack, DPA, security questionnaire support and supporting evidence under NDA.
Request the Security PackSecure Software DevelopmentSecurity should be considered throughout development — not a final checklist before launch
Concept: a secure code review on screen
IMG 03 · BUILD · coverEngineering posture
Secure software development
Security should not be a final checklist before launch. It should be considered throughout development. Security requirements vary by project — a simple marketing website does not have the same risk profile as an ecommerce store, healthcare portal, customer dashboard, financial application, AI platform or system connected to internal databases. We therefore consider security requirements during discovery and architecture rather than applying one identical checklist to every project.
Threat ModelingIdentify how features and workflows could be attacked before the system is finished.
Secure CodingUse secure development practices including input validation, output encoding, authentication controls and least-privilege principles.
Automated TestingWhere appropriate, static and dynamic security testing can be integrated into the development process.
Human ReviewAutomated scanners cannot identify every issue. Human review adds context that automated testing can miss.
Penetration TestingWhere required by the project, penetration testing can help identify vulnerabilities through simulated attacks.
Dependency ManagementFrameworks, libraries, plugins and other dependencies should be monitored and updated to reduce exposure to known vulnerabilities.
Secure DeploymentProduction environments should use appropriate hardening, HTTPS, access controls and sensible configuration.
Trust for Web, Branding and AI projects. Security requirements are not limited to software development — branding, web and AI engagements can each involve confidential information, credentials, customer data or model providers. The appropriate controls depend on what information and systems are involved.
People using assistive tech, inclusive by default
IMG 04 · A11Y · coverWhat we build in
Accessibility, privacy and payment security
Security is not the only responsibility of a digital product. Accessibility matters too. Privacy requirements should be considered when a website or application collects or processes personal information. Ecommerce introduces another layer of security around payment systems.
Accessibility
Accessibility is built into the delivery process and tested through automated and manual methods, including assistive-technology testing. Accessibility requirements can vary by jurisdiction, organization and type of digital product.
- Keyboard navigation and visible focus states
- Alternative text, color contrast and semantic structure
- Accessible forms and assistive technology testing
GDPR and Privacy
Depending on the project, privacy considerations can include data collection, consent, cookies, tracking, data processing, data-subject rights, data retention, hosting location and third-party processors. Where 10turtle processes personal data on behalf of a client, appropriate contractual and technical controls can be considered.
- Data collection, consent, cookies and tracking
- Data-subject rights, retention and hosting location
- Third-party processors and DPA support
- Consent practices and data-handling controls
Ecommerce and PCI DSS
Payment systems handle sensitive financial information, so payment architecture should be designed to reduce unnecessary exposure. Our approach references PCI DSS 4.0.1 and describes architectures designed to reduce the amount of sensitive payment data directly handled by the website. The exact PCI obligations depend on the payment architecture and the organization's role in the payment process.
- Payment providers and tokenization
- MFA, payment-script security and access controls
- Secure integrations
Accessibility built into the build
Our web development approach considers WCAG 2.1 and 2.2 Level AA requirements. Accessibility is built into the delivery process — not treated as a final checklist.
DesignBuilt inAccessibility is considered during design, not treated as a final checklist.
DevelopmentIn practiceKeyboard navigation, focus states, semantic structure, forms and contrast are engineered carefully.
ReviewOngoingAutomated, manual and assistive-technology testing appropriate to the project.
Accessibility requirements can vary by jurisdiction, organization and type of digital product. Where formal legal interpretation is required, the client's legal or compliance advisors remain the appropriate authority.
AI data security and governance
AI without unnecessary data exposure
AI introduces a new question: what happens to business data when it passes through an AI system? That question matters whether you are using AI chatbots, AI agents, RAG systems, AI automation, LLM integrations, document processing or internal AI assistants. An AI system should only have access to the information it needs.
- Our AI security approach considers data access, permissions, encryption, data flows, model providers, human oversight, tool access, logging and AI governance.
- AI systems use scoped access and encryption, with data flows documented and human involvement maintained for sensitive workflows.
- For AI agents, a secure architecture should define allowed tools, data access, action limits, approval requirements, human escalation, logging, monitoring and failure handling.
Your data
credentials · records · content
credentials · records · content
Serves your systemUsed to run your agents, chatbots and automations within defined boundaries.
Uncontrolled AI inputGood AI architecture limits unnecessary access before the system goes live.
Ask before go-live: What data does the model need? What data does the agent need? Which systems can it access? Which actions can it perform? Where should humans approve actions? What information should remain inaccessible?
Concept: a live data migration in progress
IMG 05 · MIGRATE · coverSecure website redesign and migration
Protect the data while changing the system
A redesign can create security risks if existing data is handled carelessly. A migration may involve customer records, orders, user accounts, content, media, credentials, redirects and integrations. Our migration approach starts by understanding what data exists and where it lives.
BeforeOld environmentAudit what exists. Identify sensitive information. Map systems and dependencies. Document redirects and important URLs.
AfterNew environmentValidate the transfer. Preserve redirects and SEO value. Review access. Cleanly decommission the old environment.
- Audit — understand what data exists and where it lives
- Secure migration — encrypted, access-controlled transfer
- Validation — confirm the transfer before cutover
- Redirect preservation — keep SEO value and important URLs
- Old-environment cleanup — clean decommissioning
The objective is to move the business forward without unnecessarily exposing or losing valuable information.
A working session, security in the room
IMG 06 · PROCESS · coverSecurity throughout the project
Security is not a single phase
It runs through the engagement. This approach makes security part of the project lifecycle rather than a final-week activity.
Security, woven through every step
Identify security, accessibility, privacy and compliance gaps.
Gaps surfaced before scope is finalizedDefine requirements, access, agreements and responsibilities.
Access, agreements and responsibilities aligned earlyApply secure-development and accessibility practices.
Secure by design; accessibility built into deliveryDeploy securely and continue maintenance, patching, monitoring and support.
Controlled launch; ongoing patching and monitoringIn their words
What clients say about trusting us with the keys
Trust for Web, Branding and AI
Security requirements are not limited to software development
WordPress
WooCommerce
Shopify
Webflow
Wix
AnthropicA branding project can involve confidential product information, unreleased campaigns and intellectual property. A web project can involve admin credentials, customer data and ecommerce systems. An AI project can involve business documents, internal knowledge, customer records, APIs and AI model providers. The appropriate controls depend on what information and systems are involved.
Frequently Asked Questions
Trust & Security FAQ
The current Trust page states that 10turtle holds ISO/IEC 27001, but the certificate number, accredited issuing body, certified scope, and expiry are currently marked for owner verification on the live page. Those details should be confirmed through the security pack before being used in procurement documentation.
The live page describes SOC 2 as part of its security-review posture, but the exact Type I/II status is currently marked for confirmation. Prospective clients requiring SOC 2 evidence should request the applicable report or supporting documentation.
The stated approach includes least-privilege access, encryption, and managed credential handling rather than storing sensitive credentials in plaintext.
The current Trust page states that project IP and source code are assigned to the client upon completion, subject to the project agreement.
The current delivery approach targets WCAG 2.1/2.2 Level AA and includes automated, manual, and assistive-technology testing.
The Trust page describes GDPR and CCPA readiness, privacy controls, data-processing agreements, and consent-related practices. The exact legal obligations depend on the project and applicable jurisdiction.
Yes. The current approach references PCI DSS 4.0.1 and payment architectures designed to reduce direct handling of cardholder data.
The stated approach includes scoped access, encryption, documented data flows, and human oversight for sensitive workflows. The live page also notes that certain AI data-use and retention details require owner confirmation, so those specifics should be verified during procurement.
Yes. The current Trust page says 10turtle can support SIG-style security questionnaires and provide relevant evidence, DPA, subprocessors, and other documentation through the security-review process.
The Trust page offers a DPA and security pack through the security-review process.
The stated approach is to inventory the data, use controlled migration processes, validate the transfer, preserve relevant redirects and SEO value, and cleanly decommission the old environment.
Pre-CTA moment: a confident client handoff
Need Our Security Pack?
Your security team should have the information it needs before approving a vendor
Request a security pack, DPA, security questionnaire support, relevant certification evidence and supporting documentation — or start with a free audit to identify security, accessibility and compliance gaps in your current website or store. Review the evidence. Ask the hard questions. Then decide.
Security pack & DPA Questionnaire support Free audit available