Security & data protection at Become

You can trust us with your data—we take that seriously. Become is built with privacy and security in mind across the product, infrastructure, and how we run the company.

We do not advertise formal third-party security certifications here—only how we work. What follows describes our practices today; enterprise teams can request more detail under NDA or via security questionnaires.

This page summarises our posture for prospects and customers. It is not an exhaustive technical specification; enterprise teams can request deeper questionnaires or a DPA via legal@usebecome.com.

What we focus on

Privacy-aware by design
We treat customer content and account data as sensitive. Processing follows our Privacy Policy and, for teams that need it, contractual data-processing terms.
You stay in control
You decide what Become connects to and what it can do in your product. Configuration and access policies are designed so your team can enforce least privilege.
Secure engineering
We build with widely accepted application security principles (including OWASP-oriented practices), dependency awareness, and defence in depth where it matters for our stack.
Responsible AI operations
We work to ship AI features in a transparent, governable way and to watch evolving expectations—including EU AI Act and sector guidance—so our roadmap stays aligned with how customers need to govern AI.

Application security

The Become console and APIs are designed so your team can control access, protect data, and spot misuse. Capabilities depend on your plan and product maturity; where a control is on our roadmap, your sales or success contact can confirm timelines.

Role-based access: separation between admin, builder, and read-only style roles as the product matures.
Single sign-on (SSO): support for enterprise identity providers where offered on your plan.
Multi-factor authentication (MFA): available for console users when enabled for the workspace.
Credential hygiene: strong password requirements; no shared default passwords for production tenants.
Abuse resistance: rate limits and monitoring on authentication and high-risk API paths.
Data handling: options to minimise sensitive payloads in logs and UIs where the product supports masking or redaction.
Auditability: operational and security-relevant events logged with timestamps and actor context where applicable.
Session design: short-lived tokens, rotation, and transport-only exposure patterns consistent with modern web apps.

Technical & infrastructure security

We use reputable cloud providers and a layered model so data and services stay available and defensible. Exact regions and data-residency options are confirmed during enterprise onboarding and in your order documents.

Encryption in transit: TLS for client and service connections.
Encryption at rest: industry-standard algorithms and key management via our cloud providers.
Secrets: API keys and integration secrets stored in managed secret stores; not checked into source control.
Hardening: baseline and ongoing hardening of cloud accounts and services following vendor guidance.
Logging and monitoring: centralised logs and alerts for availability, errors, and security signals.
Backups: regular backups with encryption; recovery tested according to our internal objectives.
DDoS and edge: protection via our hosting and CDN stack.
Resilience: redundant regions or zones where the architecture warrants it; autoscaling under load.
Vulnerability management: dependency scanning, patching cadence for critical issues, and periodic review.
Testing: internal security review of material changes; external assessments where appropriate for our stage.

Organisational security

Security is not only technology—it is how we hire, operate, contract, and respond when something goes wrong.

People: security awareness expectations for anyone with access to production or customer data.
Access: least-privilege access to production; MFA for administrative systems.
Devices: standard secure-configuration expectations for company laptops and mobile access.
Change management: controlled releases, previews, and rollback paths for the Services.
Vendors: due diligence on subprocessors that host or process data; agreements that include confidentiality and data-protection commitments.
Incidents: documented incident response with notification timelines aligned to our customer agreements and law.
Business continuity: plans for service restoration after major disruption; exercised on a schedule suitable to our scale.

Report a vulnerability

If you believe you have found a security issue affecting Become, please email security@usebecome.com with a concise description, reproduction steps, and your contact. We ask that you give us a reasonable time to remediate before public disclosure and that you avoid testing in ways that harm other users data or availability.