Security

• Isolation in the database. Each workspace's data is separated by row-level security, which is enabled on every table in the application. Access is decided by the database, not only by the application code in front of it.
• Roles. Workspaces have owner, admin and member roles, a read-only reviewer role for outside auditors, and a client portal where a client can view and comment on their own engagement.
• Read-only protection. Archived engagements and workspaces with a lapsed subscription become read-only, enforced in the database.
• Server-side credentials. The administrative database key is used only on our servers and is never sent to a browser.

• Multi-factor authentication. Users can enroll an authenticator app or a security key or passkey, and receive recovery codes. Workspace owners can require multi-factor authentication for everyone, and it is required by default for new workspaces.
• Session timeout. Workspaces sign members out after a period of inactivity. The default is 8 hours and administrators can shorten it.
• Single sign-on. SAML single sign-on is available for Enterprise customers.
• No passwords. CISO Doc does not use passwords, so there is nothing to reuse, guess or leak. You sign in with Google, your company's single sign-on, or a one-time code sent to your email address. Codes expire quickly and work once, and multi-factor authentication still applies after a code is entered.
• Bot protection. Sign-in and sign-up forms are protected by Cloudflare Turnstile, which checks that a request comes from a real browser before an account or code request is processed.

A workspace can connect GitHub or Google Workspace so that CISO Doc reads security settings for it instead of someone typing them in. This is what happens, and what does not.

• Read-only, and only what you choose. The connection is a GitHub App with read-only permissions that you install, on the repositories you pick for each engagement. It cannot change anything in GitHub, and you can remove it there at any time.
• What is read. Whether the default branch is protected and how (required reviews, status checks, force-push and deletion rules); the people with administrator access; whether an organization requires two-factor authentication; and whether dependency alerts and secret scanning are on, with the number of open dependency alerts. Not source code, issues, pull request contents or secrets, and anything that looks like a credential is rejected before it is stored.
• A person decides. Each reading is stored as a proposal. It counts toward a control only after a named person accepts it, only while it is confirmed recent, and then only as a suggested partial status. It never marks a control as implemented, and an assessment made by a person always takes precedence.
• Not seeing is not the same as absent. If a setting cannot be seen, for example for lack of permission, it is recorded as not readable. It is never presented as evidence that the setting is off.
• A record that cannot be rewritten. Each reading carries a hash of what was observed and cannot be edited afterward, which the database enforces. A change is stored as a new reading. Every accept and reject is written to the audit trail with who made it and when, and the readings are included in the audit pack.
• Google Workspace. The client's own Google Workspace administrator signs in to Google and approves read-only access. We ask for exactly two read-only permissions, to see the list of accounts and to see admin roles, and nothing that reaches mail, Drive, calendars or files. What is read is whether each active account is enrolled in 2-Step Verification, who the administrators are and their roles, and which accounts are suspended, archived or have not signed in for 90 days. The snapshots include the email addresses of those staff (up to 50 per list). The access can be removed at any time, from CISO Doc or in the Google Admin console.
• The Google credential is encrypted. The long-lived Google credential is encrypted by us before it is stored, with a key held outside the database, in a table that no signed-in user can read. Disconnecting revokes it at Google and deletes it.
• No stored GitHub token. GitHub issues a token that lasts one hour for each collection run. The key that signs those requests is held only on our servers.

Security-relevant actions are recorded: sign-ins and sign-outs, document creation, saves and exports, permission changes, data exports, and decisions to accept or reject collected evidence. Records cannot be edited or deleted, which the database enforces, and are kept for seven years. Workspace owners and admins can view them and download a copy.

• In transit. All traffic to CISO Doc is served over HTTPS.
• At rest. Our database and file storage provider encrypts stored data.
• Integration credentials. The access tokens for a connected Slack or Google account are additionally encrypted by us before they are stored, with a key that is held outside the database.
• Files. Uploaded documents and evidence are stored privately and opened through short-lived links. Only workspace logos, which appear on branded exports, are public.
• Vendor questionnaire links. Each link carries a random token. We store only a hash of it, and the link expires after 30 days.
• Spreadsheet exports. Exported spreadsheets neutralize formula injection from free-text answers.

We monitor dependency vulnerability alerts and fix them as they are raised.

Anyone can download their personal data and delete their account from account settings. Workspace administrators can set how long archived engagements are kept and permanently purge them afterward. Our Privacy Policy lists the providers that handle data. Data is hosted in the United States today, and we are preparing an EU region.

If you believe you have found a security issue, email [email protected] with the details. Please do not access data that is not yours or disrupt the service while testing.