Cloud Sentry
Trust Center

Our own security posture, in the open.

We hold ourselves to the standard we run for you.

Three ways we earn trust

A trust page is a start, not the whole answer. Here is the full stack, and where each piece lives.

01

Our own posture

What you are reading right now: the certifications we hold or are working toward, the practices we run day to day, and the sub-processors behind our own stack.

02

What you inherit

When we operate part of your environment, our controls become controls you can point to. See what carries over, and what stays yours to own.

The inherited-controls matrix
03

Proof on demand

Auditors and reviewers should not have to take our word for it. Scoped, time-bound access lets them check the evidence themselves.

The Evidence Vault

The controls

What we run, control by control.

Grouped by the SOC 2 domain each one answers to. Green means it is in place today. Amber means it is real with a boundary worth naming. Where a third party has yet to verify something for itself, we say so further down.

Access control

CC6 · Logical and physical access

  • MFA on every account (In place)

    Multi-factor authentication is required across the systems we run our business on.

  • Least-privilege access (In place)

    People hold the narrowest access that lets them do the work, and it is reviewed when roles change.

  • Single sign-on (In place)

    Portal access runs through a single identity provider, so joiners and leavers are handled in one place.

  • Quarterly access reviews (In place)

    A scheduled re-check of who holds what, with the result recorded.

Data security

C1 · Confidentiality

  • Encryption in transit and at rest (In place)

    Customer data is encrypted on the wire and on disk across the systems we operate.

  • Backups (In place)

    The systems of record we run are backed up, with restores exercised rather than assumed.

  • Data erasure on exit (In place)

    A defined path for returning and then removing customer data at the end of an engagement.

  • Endpoint management (In place)

    Company endpoints are enrolled, encrypted, and centrally managed.

Monitoring and response

CC7 · System operations

  • Logging and monitoring (In place)

    Security-relevant events are collected centrally and reviewed.

  • Audit logging (In place)

    An append-only record of who did what, readable after the fact.

  • Incident response plan (In place)

    A written plan naming who decides, who communicates, and how fast.

  • Customer incident notification (In place)

    If something goes wrong in an environment we operate, we tell you what happened and what changed.

Secure development

CC8 · Change management

  • Code review before merge (In place)

    Changes reach production through review rather than direct pushes.

  • Dependency and vulnerability scanning (In place)

    Automated checks run on every change, and high-severity findings block the merge.

  • Secure development training (In place)

    Engineers receive role-appropriate secure-development training on a schedule.

  • Application penetration testing (In place, with a boundary)

    An independent test of the application by a third party.

People and governance

CC1 · Control environment

  • Background checks (In place)

    Staff who can reach customer environments are screened before they start.

  • Security awareness training (In place)

    Annual training for everyone, with completion tracked.

  • Written policy set (In place)

    Acceptable use, access control, and the rest, versioned with a change history.

  • Policy acknowledgement records (In place)

    A record of who accepted which version of which policy, and when.

Risk management

CC3 · Risk assessment

  • Risk register (In place)

    Risks are recorded with an owner, a treatment, and a review date.

  • Compensating controls carry an expiry (In place)

    A temporary control is dated, so it comes back for a decision rather than becoming permanent.

  • Annual risk assessment (In place)

    A scheduled review of the whole register rather than ad-hoc updates.

Vendor management

CC9 · Risk mitigation

  • Vendor review before onboarding (In place)

    New vendors are assessed before they touch anything of ours or yours.

  • Published sub-processor list (In place)

    Every sub-processor behind our own stack, named, with what it is used for.

  • Sub-processor change notice (In place)

    Advance notice before a new sub-processor starts handling customer data.

Privacy and legal

P1 · Privacy

  • Data Processing Agreement (In place)

    A DPA available to sign, covering how we handle personal data on your behalf.

  • Certificate of Insurance (In place)

    Current cover, available on request.

  • Data portability on exit (In place)

    What we build and document for your environment is yours, and leaves with you.

  • Written offboarding commitment (In place)

    A public document spelling out what you keep, what we hand back, and how long it takes.

AI governance

  • Customer data stays out of models (In place)

    Sensitive customer data is kept out of third-party models.

  • AI used for awareness, with people deciding (In place)

    Automation surfaces and drafts; a named person makes the call and carries the accountability.

  • Written AI acceptable-use policy (In place)

    An internal policy governing which tools staff may use and with what data.

Control names and domains follow the same Trust Services Criteria set behind our inherited-controls matrix, which shows which of these carry over to your environment when we operate it.

Independent attestations

Third-party findings about our own environment. We publish the state of these the same way we would want a vendor to publish theirs.

SOC 2 Type II

An independent report on our own controls, observed over a period.

Not yet

ISO 27001

Certification of our own information security management system.

Not yet

Independent penetration test

A third-party test of our own application and infrastructure.

Not yet

On our 2027 roadmap. All three sit on the 2027 plan. We publish the state of each one here as it lands, so this section stays the current answer rather than a promise you have to chase.

How we operate, day to day

These are the practices we operate today, described as our approach, not as audited or certified claims.

Encryption in transit and at rest

Traffic to and from our systems is encrypted end to end. Data at rest is encrypted wherever we control the storage layer.

Least-privilege access

Access is scoped to what a role needs, reviewed on a schedule, and revoked the moment it is no longer needed.

MFA everywhere

Multi-factor authentication is required across the tools our team uses to operate your environment. Not optional for the people holding the keys.

Endpoint management

Every device our team uses to touch a customer environment is enrolled, monitored, and held to a security baseline.

Logging and monitoring

Access and administrative actions are logged. We monitor for the signals that matter, not just the ones that are easy to collect.

Secure development

Where we build our own software, security review is part of how it ships. It applies to what we build ourselves, not every third-party tool we use.

Sub-processors

We rely on a small number of sub-processors to run the Marketing Site and the Support Portal. Each one is contractually bound to handle data only on our instructions.

Cloudflare

Hosting, edge security, and the database and storage layer behind the Support Portal.

WorkOS

Single sign-on for the Support Portal.

Resend

Transactional email for Support Portal notifications.

Stripe

Payment processing for customers who purchase services.

DocuSign

Electronic signature for policies and acknowledgements.

Calendly

Scheduling for discovery calls booked from this site.

Intuit QuickBooks

Invoicing and billing records.

If you sign in with Google or Microsoft, that provider authenticates you directly. The full list, including what each provider processes and a link to their own security page, lives in our Privacy Policy. We review this list every time we add or change a sub-processor.

What we commit to

Your data, your portability

We design around portability. What we build and document for your environment is yours, and we commit to a clean handoff whenever you choose to make one.

An offboarding commitment you can ask for

Ask us and we will walk you through exactly what you keep, what we hand back, and how long a clean handoff takes.

Incident transparency

If something goes wrong in an environment we operate, we tell you directly: what happened, what we did about it, and what we changed so it does not happen again.

See how the rest of the stack holds up.

Read the published plan structure, or walk the full operated partnership.

Published structure, a written annual escalator cap, and an entry rung you can start today.

The scope, the visibility, and the work we do not take on, laid out section by section.