1. Our approach.
We treat security as part of engineering and operational hygiene, not a compliance afterthought. Each engagement starts with a conversation about the data involved, the systems it touches, and what “good” looks like for the client’s risk posture. We aim for defaults that are conservative without being theatrical, and we document what we do.
2. Information-security program.
We are building an internal information-security program modelled on the control families of SOC 2 and ISO/IEC 27001: governance, access control, change management, vulnerability and patch management, vendor risk, incident response, and physical and personnel security.
We have not completed a formal SOC 2 or ISO 27001 audit, and nothing on this page is a third-party attestation or certification. We separate below what we have confirmed from what we work toward, and we will move an item from the second list to the first only when we have checked it. Our roadmap is in Section 10.
3. Identity and access.
Confirmed.
- Sign-in to our Zoho administration console and to our payables system uses a second factor.
- Credentials, API keys and secrets live in a managed secret store, never in source code or in files.
Our practice, and not yet confirmed system by system.
- Multi-factor authentication on every business system that supports it, including email, source control, project management, cloud consoles and password management. We are confirming the setting on each system and will list the systems here as we do.
- An organisation-managed password manager, and no shared accounts or personal passwords for business systems.
- Least-privilege access scoped by role, with sensitive systems (production cloud consoles, secret stores, client production data) limited to the smallest set of people who need them, and access removed promptly when a role changes or a person leaves.
4. Endpoints.
Our practice is managed endpoint protection and full-disk encryption on every staff workstation, current operating-system and browser updates with critical patches applied promptly, and a documented lost-or-stolen-device process that includes remote wipe, credential rotation and notice to affected clients. We have not yet confirmed each of these on every device, and we do not claim them as verified.
5. Code and engineering practices.
- Changes to this website are made on a separate branch, built and checked, previewed, approved by a named person, and then merged and released from the main branch.
- Secrets, API keys, and credentials live in a managed secret store, never in source code, screenshots, or chat.
- We use lockfiles for dependency reproducibility and monitor dependency advisory feeds for known vulnerabilities in the packages we ship.
- Development, staging, and production environments are separated; real client data is not used in development or staging without explicit written permission and documented controls.
- Traffic to this website is encrypted in transit (HTTPS with HSTS), and our email domain publishes SPF and DMARC records that reject forged mail.
6. How we handle client engagements.
- Where possible, we work inside the client’s own environments (the client’s cloud account, the client’s source control, the client’s productivity suite) so that data does not leave their perimeter.
- Every engagement is governed by a written agreement that includes confidentiality obligations and, where appropriate, a data-processing addendum (DPA).
- We follow the principle of data minimisation: we ask for the least data we need to do the work, and we delete or return it at the end of the engagement.
- We do not commingle data across clients. Each client’s data and credentials are isolated.
- Subcontractors who touch client data are bound by equivalent confidentiality and security obligations to those we owe the client.
7. Service providers.
The following third parties are used to operate our business and may, in the ordinary course, process information that touches the Site or a client engagement. The Privacy Policy describes what each receives about visitors to the Site.
- Wix.com, Ltd. — Israel / United States. Hosting, content management and the Site’s platform.
- Cloudflare, Inc. — United States and its global network. Content delivery and attack protection that Wix uses.
- Google LLC — United States. Google Workspace (business email, calendar and document collaboration), Google Analytics 4, the Google Ads tag and embedded video.
- Consentik and GeoJS — the cookie banner and its location lookup.
- Zoho Corporation — United States / India. CRM, forms, booking, marketing automation, the chat, and project and business-operations tooling.
- Zoom Video Communications, Inc. — United States. Meetings and recordings.
- Anthropic, PBC — United States. The Claude AI model that summarises meeting transcripts and classifies inquiries.
- Slack Technologies, LLC — United States. Internal messaging.
- GetProspect and Bright Data Ltd. — business contact and public web data used to enrich inquiries.
- Bill.com, LLC — United States. Invoicing and payments.
- HeyGen Technology Inc. — video production.
- GitHub, Inc. — United States. Source control and code review.
When a client engagement requires a provider outside this list, we will disclose it in the engagement agreement before any client data is processed.
8. Incident response and breach notification.
We keep an internal incident-response plan. If we become aware of a security incident that affects systems we operate or client data we hold, we will:
- Contain and investigate without unnecessary delay.
- Notify affected clients without undue delay, in keeping with our contractual and statutory obligations (including, where applicable, EU/UK GDPR’s 72-hour timeline to supervisory authorities).
- Share as much information as we reasonably can about what happened, what data was involved, and what we are doing in response, and update that picture as the investigation progresses.
- Conduct a post-incident review and apply the lessons to our controls.
9. Responsible disclosure.
If you believe you have found a security vulnerability in this Site or in a system we operate, please tell us. We will work with you in good faith.
- Email security@codestringers.com with a description of the issue, the affected system or URL, steps to reproduce, and any proof-of-concept material. Please do not include sensitive personal information in your report.
- We will acknowledge your report within five business days and keep you informed as we investigate.
- We ask that you give us a reasonable window before public disclosure: by default, 90 days from your report, extendable by agreement if the fix is more complex.
Safe harbour. We will not pursue legal action against good-faith security research that respects privacy, avoids destruction or modification of data, does not degrade the service for others, and follows this policy. Please do not access more data than necessary to demonstrate the vulnerability, and do not exfiltrate, retain, or share data you encounter.
We do not currently operate a paid bug bounty program. We do credit researchers who report valid issues, with their permission.
10. Roadmap.
We are working toward confirming the practices in Sections 3 and 4 system by system and toward formal certification against SOC 2 and/or ISO/IEC 27001. When we have a third-party report or letter to share, we will publish it on this page, or make it available under NDA to clients and prospects on request. Until then, what this page attests to is the confirmed list in Section 3 and the practices in Sections 5 and 6.
11. Contact.
For security questions, vulnerability reports, or customer security questionnaires:
Security Team, CodeStringers
security@codestringers.com
Consultation form
