Security at SprintLoop

Every record SprintLoop stores carries the organization that owns it, and the database refuses any read or write that crosses that line. The boundary is attached to the data itself rather than to the screens in front of it, so it holds the same way for a browser request, a background job and a support query.

The application checks the signed-in person’s organization and role as well. That check is the first line; the database boundary is the one that still holds if a query is ever written incorrectly. Relationships between records carry the organization too, so a link from one customer’s work to another’s is not a bug that behaves like a working join — it is rejected before it is stored.

Before a release ships, a real signed-in identity from one organization attempts to read and write the records of organizations it does not belong to, through the same interface a browser uses. Every attempt has to be refused. The run enumerates what to try from the live schema rather than from a checklist, so anything added to the product is covered by the next release rather than by somebody remembering it.

Administrators can see the same result for their own tenancy inside their workspace, with the date it was produced.

Last verified 19 August 2026, 1 day ago: no record belonging to another organization was readable, and no write into one was accepted. This is the record of a run at a moment, not a live check.

• In transit. Every connection — browser to application, application to database — is TLS 1.2 or above. There is no unencrypted listener to reach.
• At rest. The database and its backups are stored encrypted with AES-256 on managed infrastructure.
• Where it sits. Customer data is held in the United States and nowhere else. Pages that carry no customer data are cached on a global network, which is why the site loads quickly from anywhere without any register content leaving the country.

Regions, key management and the limits of what we will put in a contract are set out in control detail.

• Nobody starts with access. A new account reaches nothing until an administrator places it in one workspace at one role. There is no cross-organization role and no global search: to somebody outside a workspace, the database answers exactly as it would to a stranger.
• Roles separate two kinds of authority. Administering a workspace and holding authority over delivery evidence are deliberately different grades, so managing membership does not carry the power to publish evidence, change billing or transfer ownership.
• Two-step verification. Any member can enroll a time-based code from an authenticator app. Once enrolled it cannot be skipped, and enrollment issues single-use recovery codes that are shown once and never emailed. No support process here can remove somebody’s second factor on request.
• Passwords are never ours to lose. Credentials are exchanged with the identity service; this application never receives, stores or logs a password or a verification code. Passwords must be at least twelve characters and are checked against a public breach corpus and refused if they appear in it.
• Sessions expire, and privileged acts re-ask. A session ends after eight hours idle or twelve hours in total, and ending it revokes it at the identity service rather than only clearing the browser. The twelve-hour ceiling is measured from the sign-in recorded inside the session token itself, so it cannot be reset by clearing a cookie; the idle timer is held by the browser and is the looser of the two. Changing how people sign in to a workspace requires proving your identity again within the last fifteen minutes, and removing your own second factor requires that factor or an unspent recovery code.
• Single sign-on. SAML 2.0 for Microsoft Entra ID and other standards-based providers is built into the product and enabled per deployment during onboarding. Its current activation status is stated in control detail.

Every act that changes what the register claims is appended to a trail: who did it, what changed and when. The actor comes from the authenticated session rather than from anything the client sends. Deletion is blocked for workspace users, for owners and for privileged platform roles, and each release proves that boundary by attempting the deletion and being refused.

The trail is kept for the life of the tenancy. It does not roll off on a schedule and it is not something a plan can buy more of.

There is a monitored security mailbox and a published disclosure policy. The mailbox was verified end to end with a real message before this page named it, because an address that bounces silently turns a researcher trying to help into one who concludes nobody is listening.

Security contact: security@theboardwalk.ai — also published machine-readably at security.txt (RFC 9116) with the scope notes. Tenant isolation is in scope and is the finding we most want.

• Backups. Daily encrypted backups with point-in-time recovery, managed at the database platform layer.
• Dependency posture. Dependency advisories are triaged for reachability, and the tests that establish an advisory is unreachable are kept so the classification can be re-checked rather than believed.

Recovery objectives and support commitments are commercial terms, settled in the agreement for the estate in question. What this deployment does and does not commit to today is stated in control detail.

The services that handle customer data on our behalf, and what each one receives. Notice and objection rights are established in commercial terms.

Control detail is written for the questionnaire: mechanisms stated precisely, the boundary of each one, and what is not implemented. Send anything it does not answer to the security team and you will get a direct answer rather than a deflection.

Contact securityControl detail