A careful approach to data security and platform integrity
This page describes our current security approach using claims we can support from the platform and internal documentation. Roadmap items are identified separately from controls that are already in place.
Current Controls
Security claims we can support today
Access control
Authentication via Firebase Auth, role-based permissions, and row-level security in the database.
Platform integrity
Audit logging and project chronology patterns are used to support traceability across project activity.
Data protection
Encryption in transit, encryption at rest, and core data stored in Google Cloud London (`europe-west2`).
Operational access
No routine staff access to customer project data. Support access is only provided when authorised and is logged.
Threat Mitigation
Defence-in-depth where it matters most
Our security model is intended to combine identity, permissions, database enforcement, auditability, and infrastructure controls rather than relying on a single layer.
Examples
- Tenant isolation is enforced at the database layer with RLS.
- Files and BIM pipelines use validation controls including IFC header checks and zip-bomb protections.
- OAuth tokens for Autodesk integrations are documented as encrypted with AES-GCM.
- Signed URLs are used for cloud file access rather than direct bucket exposure from the browser.
Certification Alignment
Controls in place, certification work still in progress
We track our roadmap against the controls already present in the platform. Today, we can support claims around identity-based access control, row-level security, audit logging, encryption, signed URL file access, and documented AI security controls. Formal certification still depends on policy maturity, operational evidence, and external validation.
Cyber Essentials
Nearest certification target. Current work is focused on documentation, validation, and operational evidence.
SOC 2 Type II
Future target that depends on sustained control operation, policy maturity, and external audit readiness.
ISO 27001
Longer-term target that would require a formal information security management system and audit cycle.
Vulnerability Disclosure
Report a vulnerability
If you think you have found a security vulnerability in Win Win Designs, tell us privately at security@winwindesigns.com. Please don't report it in public. We welcome reports and will work with you on a fix.
What to expect
- Acknowledge your report
- 3 working days
- Initial assessment, including severity
- 10 working days
- Progress updates until it is resolved
- At least every 14 days
Testing in good faith
- Use only accounts and data that are yours. If you reach anyone else's data, stop, report it, and delete what you have.
- No denial of service, load testing or high-volume automated scanning.
- No social engineering, phishing or physical attacks.
Scope
- In scope: winwindesigns.com and its subdomains, the Win Win Designs web app and its APIs.
- Out of scope: third-party services we use, such as Google Cloud, Firebase and Stripe. Please report those to the provider.
- Not accepted: scanner output without a demonstrated impact, missing headers without an exploit, and self-XSS.
Research that follows these rules in good faith is authorised by us, including for the purposes of the Computer Misuse Act 1990, and we will not take legal action or refer it to law enforcement. Please keep details private until we have fixed the issue, or for 90 days from your report, whichever comes first. We credit reporters who would like to be named; there is no paid bug bounty. Machine-readable contact details: security.txt.
Honest security communication matters
We would rather publish narrower, verifiable claims than overstate our posture. As controls mature, this page can expand with more detail and stronger external evidence.