Your data is kept apart from every other business
Every record in SKEDS carries the id of the business it belongs to, and the database itself enforces that boundary on every read and every write using row-level security. The app cannot ask for another business's data by mistake, and neither can a person who signs in: the rule is applied by the database, not by the screens. Inside a business, what each person can see and change is decided by their role (owner, manager, dispatcher, field tech, read only), and those checks are also made by the database on every request.
Signing in
Sign-in is handled by our authentication provider. Passwords are never stored by SKEDS in readable form; they are stored as salted hashes, and new passwords are checked against known breach lists so a password that has already leaked elsewhere is refused.
Two-factor authentication (a code from an authenticator app as well as your password) is available to every person, and an owner can require it for chosen roles. Sessions sign out after a period without activity, and any person can sign out every device at once from Settings.
Encryption
Every connection to SKEDS and to its database uses HTTPS (TLS), and browsers are told to remember that so a plain http address is never used. The database and file storage are encrypted at rest by our infrastructure provider.
Files you upload
Photographs, documents and attachments are stored in private buckets. They are never at a public address: the app opens each one through a short-lived signed link created for the signed-in person. Buckets accept only the kinds of file the app invites (images, PDFs, office documents, plain text and CSV) and cap each file's size.
In your browser
The app sends a strict Content-Security-Policy that names the only places code, styles, images and data may come from; every third-party library is pinned to an exact version with an integrity hash, so a library file altered anywhere between its publisher and your browser is refused. SKEDS cannot be framed by another site, and browsers are told not to guess file types.
Who touched what
Changes to jobs, clients, quotes, invoices, payments, settings, roles and safety documents are written to an audit trail with who made them and when. Owners and managers can read the administrative part of it under Settings.
Services SKEDS relies on
SKEDS is built on a small number of providers, each used for one thing: a cloud platform for the database, sign-in and file storage; a host for the website; an email service for the messages SKEDS sends on your behalf; a payment processor; map and address-lookup services for the map and job pages; and an AI provider for the in-app support assistant, only when a business chooses to use it, which sees the question asked and the records that person is already allowed to see. Each provider receives only what it needs, and the current list is kept in our Data Processing Agreement, available to business customers on request.
Testing our own security
We evaluate the whole stack against a production-security checklist, and we run our own penetration test that tries to reach one business's data from another account: every case is blocked, because the database enforces the boundary, not the screens. The audit scorecard and the test record are available to business customers under a confidentiality agreement.
Where SKEDS is honest about its limits
A security page that overclaims is itself a security problem, so here is what SKEDS does not do yet:
- Uploaded files are not scanned for malware. The app checks a file's type and size and marks it as unscanned; unscanned documents can be opened by office roles only.
- No single sign-on (SAML) yet. Sign-in is email and password, with optional or required two-factor.
- No independent third-party penetration test has been published yet. Our infrastructure providers publish their own; SKEDS's own external test is on the roadmap.
Reporting a security concern
If you believe you have found a vulnerability, email security@skedsapp.com. Please give us a reasonable time to fix it before making it public; we will acknowledge your report and tell you what we did.