Security & Data Handling

This site and our own infrastructure run on Vercel, with AWS and GCP used depending on the project. Where we deliver work into a client's own cloud account, that account's security configuration is governed by the client, not by us.

In transit: enforced site-wide via HTTPS (automatic TLS) and a Content-Security-Policy directive that upgrades any insecure request.

At rest: we rely on our infrastructure providers' (AWS, GCP) default encryption-at-rest capabilities. Where a project runs in a client's own cloud account, encryption-at-rest is governed by that account's own configuration.

Access to client systems, repositories, and credentials is granted on a least-privilege basis — only the people working on an engagement get access, only to what that engagement requires.

Multi-factor authentication is enabled wherever a client's own security policy requires it. We are not yet at a universal internal baseline requiring it on every account regardless of client requirement, and we'd rather say that plainly than imply otherwise.

Every engagement is covered by a signed NDA where the client's data calls for one. Separately, we are formalizing a standing confidentiality agreement that every team member with system access signs, independent of which specific client they're working with — so confidentiality doesn't depend on a particular client having thought to ask for it.

Our access to a client's systems, credentials, and any working copies of client code or data is revoked and deleted within 90 days of project completion, unless an active support or retainer arrangement continues past that point. Anything delivered to the client under the engagement agreement remains theirs regardless of this timeline — this governs our own copies and access, not what we built for you.

We have a defined internal process for handling a security incident: detection and internal escalation, assessing which client(s) are actually affected, containment and remediation, and notifying any affected client once impact is confirmed. We're still refining the specific commitments (who owns this, exact notification timeframes) and would rather finish that properly than publish a number we haven't actually committed to internally yet.

Two things we don't have a formal practice for yet, stated plainly rather than glossed over: a defined backup practice for client work-in-progress, and a formal vetting process for staff or contractors before they get system access. If either of these matters for your evaluation, ask us — we'd rather have that conversation directly than let a gap sit unaddressed on a page nobody reads closely.

Third-party services that touch data related to this site or our engagements:

• Vercel — hosting
• PostHog — site analytics, loaded only after visitor consent
• Discord — lead and notification routing
• WhatsApp Business — client communication
• Xendit, Midtrans, Stripe — payment processing

A specific engagement may introduce its own subprocessors — the client's own cloud account or third-party integrations aren't covered by this general list.

We'll update this page as our practices change — including updating the gaps in §7 once they're actually closed, not before.

Questions about our security practices, or need a completed vendor security questionnaire?

• Email: [email protected]
• Website: solutive.app