Security overview

Identity and access

Single sign-on against your own directory. Sanderwell can authenticate against Microsoft Entra ID, so accounts are created, disabled, and de-provisioned by the directory you already run, and your existing multi-factor and conditional access policies apply unchanged because we are not the thing enforcing them. This is the configuration we recommend, and the one to ask for if de-provisioning on separation matters to your review.

Without it, accounts are local to the application and passwords are stored hashed, never recoverable and never visible to us. It is a supported configuration where you are not ready to federate, but it puts the de-provisioning obligation on your finance office rather than on your directory, and we will say so rather than let it pass unnoticed in a review.

Permissions are granular and role-based. Seeing another traveler's form, editing one, approving one, changing a form's status, and exporting an audit packet are separate rights, granted separately. Approval routing keys on the department and the account together, so authority to approve a form is not authority to approve every form.

Where the data lives

In the United States, with a major cloud infrastructure provider. The application, the database, and secret storage are all managed services from a single provider, in a US region. We name the provider and the region in writing on request and in the security questionnaire. We do not run our own datacentre and do not pretend to.

Encrypted in transit and at rest. Traffic is HTTPS-only and HSTS is enforced, so a downgrade to plain HTTP is not available. Stored data and uploaded files are encrypted at rest by the managed services holding them.

No credentials in configuration. Connection strings, API keys, and mail credentials come from a managed secret store at runtime, not from files in the deployment. In production the application authenticates to that store with a workload identity rather than a key of its own.

Backed up as a managed service, with point-in-time restore. We will give you the retention window and our recovery objectives in writing rather than round them off here, since those are exactly the numbers a review needs to be accurate.

Isolation between customers

Every customer is a separate organization in the system, and every query is scoped to the organization the request resolved to before it reaches data. Your travelers, policy configuration, account structure, approval routing, and uploaded receipts are reachable only from your own tenant. A user account exists inside one organization; there is no cross-organization role, including for us.

Uploaded files

Receipts and supporting documents are the untrusted input in a travel system: they arrive from anyone who can file a form. Every upload is scanned for malware and held in quarantine until a verdict comes back — a file with no verdict yet is not downloadable, so a clean scan is a precondition of the document being usable rather than a check that runs afterwards. Files are stored in per-organization private storage and served through the application, never from a public URL.

The audit trail

Access to personal information is logged, and so is every audit-packet export. Those records exist because your finance office and your auditors ask who looked at what, and because a system that cannot answer that question fails a review on its own. Form status changes carry who made them and when, which is the same trail an auditor follows through an approval.

Your data, and getting it back

The data belongs to your organization. We process it to run the service under our agreement with you and on your instructions. We do not sell it, mine it, or use it to train anything.

Exit is written into the agreement, not left to goodwill. On termination you get a full export — structured data as CSV and the generated documents as PDF — and we then delete what we hold within an agreed window and confirm the deletion to you in writing. You should not have to take our word for it afterwards, which is why the confirmation is a term rather than a courtesy.

Answering your security review

We complete the HECVAT — the Higher Education Community Vendor Assessment Toolkit — for the colleges and universities that use it, and your own questionnaire if you use a different one. Send it during the evaluation rather than at contract signature; it is the step most likely to add weeks, and it is the one we can start earliest.

What we have not yet done

We hold no third-party security certification. No SOC 2, no StateRAMP. We are early, and a certification we have not earned is not one we are going to imply. Ask specific questions about how the system is built and we will answer them specifically.

We have not commissioned an independent penetration test. One is planned. Until it exists, treat the claims on this page as our own account of our own system, and ask us to demonstrate anything you want to see for yourself.

We do not publish a standard data processing agreement. One is in preparation. In the meantime we will review and sign yours, which is what most organizations want anyway.

Reporting a vulnerability

If you believe you have found a security issue, tell us before you tell anyone else. We will treat it as a problem to fix and you as someone who did us a favor. Include what you did, what you observed, and how we can reproduce it. We will acknowledge you within one business day.

This overview covers the Sanderwell Travel & Expense application. It is a summary written for a first review, not a contract; where it conflicts with a signed agreement, the agreement governs. Last updated August 2026.