Last updated: [EFFECTIVE DATE]
Tenant isolation
Each customer's business data is isolated at the database layer using row-level security tied to an authenticated tenant context, not only application-level filtering. Application code also independently verifies that a request's authenticated tenant matches the data it is asking for before returning or modifying it.
Platform administration
Internal platform-administration actions (like changing an account's status or billing configuration) are performed by individually identified platform administrators, each with a defined role and a specific set of permissions. There is no shared password or shared credential that performs these actions anonymously. A one-time setup credential exists only to create the very first administrator account and cannot be used afterward to authenticate or to perform ordinary administrative actions.
Sessions & credentials
Login sessions use a randomly generated, single-use session token. The server stores only a cryptographic hash of that token, never the token itself, and every request re-verifies that the session has not expired, been revoked, or been issued to an account that is no longer active. Passwords are never stored in plain text; they are hashed before storage using a standard, salted password-hashing algorithm (PBKDF2).
Confirmation controls
Sensitive administrative actions (such as suspending, cancelling, or changing the billing of a customer account) require a two-step process: the system first issues a server-generated confirmation tied to the specific authenticated administrator, the specific action, and the specific target, which expires if unused; only a matching, unexpired, not-yet-used confirmation can then execute the action. The client cannot substitute a different action, target, or argument between the two steps.
Audit logging
Administrative actions are recorded with the identity of the administrator who performed them, what was done, what changed, and whether the action succeeded. The actor recorded in that log always comes from the authenticated session, never from a value a client submitted. On our production database, historical audit records cannot be altered or deleted after the fact, including by the database's own administrative role.
Data in transit
Connections to SCOUT are made over HTTPS. Session cookies are restricted to secure, HTTPS-only transmission.
Access control
Within a customer account, team members are assigned roles that determine what they can see and do. Within SCOUT's own platform-administration layer, separate roles determine which administrative actions a given administrator may perform, enforced at the point the action is executed, not only in the interface.
Reporting a security concern
If you believe you've found a security vulnerability in SCOUT, contact [SECURITY CONTACT EMAIL]. Please do not test for vulnerabilities against other customers' accounts or data. We will acknowledge reports and investigate in good faith. Attorney/business review: define a formal response-time commitment and safe-harbor language for good-faith researchers before publishing this as a binding commitment.
Security incidents
If we confirm a security incident that affects your account data, we will notify you within [BREACH NOTIFICATION TIMELINE], consistent with applicable law and our agreement with you. See the Security Incidents section of our Terms of Service and our Data Processing Addendum for the contractual commitment.
What we don't claim
SCOUT does not currently hold SOC 2, ISO 27001, HIPAA, or PCI DSS certification, and we do not claim encryption at rest, 24/7 security monitoring, guaranteed uptime, or independent penetration testing unless and until those are actually true and verifiable. This page will be updated if that changes. No security control, here or anywhere, eliminates all risk, and SCOUT does not promise that a breach or unauthorized access can never occur -- see the Disclaimers and Limitation of Liability sections of our Terms of Service.