Policies
Security overview
How the desk and portal protect investor, borrower and deal information, written as answers to the questions in a typical bank or investor vendor security questionnaire. Each answer names the control behind it.
In brief
- Every person signs in to their own account, invited by an administrator. Roles are enforced by the database itself, not the browser.
- Two-factor sign-in, one live session per person, and an optional network allow-list for administrators.
- An append-only, hash-chained access log, checked every night and timestamped by outside services.
- Encrypted nightly backups and a weekly restore drill that loads the newest backup into a fresh database.
- Not yet: a SOC 2 report or an outside penetration test. Both are scoped; see the bottom of this page.
These answers describe controls that exist in the software as of October 2026. They are not a certification or an audit opinion. Items marked When set up depend on a one-time configuration step; items marked Not yet are gaps we are working on. For a completed questionnaire in your own format, use the contact on our plans page.
1. Access control and sign-in
| Question | Answer | Control |
|---|---|---|
| How are user accounts created? | By invitation only. The first account becomes the administrator; every later sign-up is refused by the database unless an administrator has invited that email. Public self sign-up is off. | AC-1 |
| Are accounts individual? | Yes. One named person per account. Signing in somewhere new ends that account's other sessions, and the server gives the old session no access. | AC-1, AC-4 |
| How is access limited by role? | Four desk roles (administrator, caller, researcher, viewer). Row-level security on every database table and role checks in every server function decide what each role can read or change, so changing the browser code does not grant more access. Viewers never see contact details. | AC-2 |
| Is multi-factor authentication supported? | Yes: authenticator-app codes (TOTP). Once a person enrols, the server refuses any session that has not passed the code check. Administrators can require two-factor for administrators or for everyone. | AC-3 |
| Password rules? | At least 12 characters, changed at first sign-in. Passwords are handled by Supabase Auth; we never store them ourselves. | AC-1 |
| Session timeout? | Signed out after 30 idle minutes. Viewers are not kept signed in between visits. "Sign out everywhere" is available to each user. | AC-4 |
| Single sign-on? | Google or Microsoft sign-in, when an administrator switches the provider on. SAML is not offered. | AC-7 |
| Can administrator access be restricted by network? | Yes. An optional allow-list of IP addresses; outside it, administrator powers are refused by the database. | AC-5 |
| How do outside parties (investors, banks, issuers, borrowers) get access? | Through a separate portal login that sees only the deals they have been added to. Offering documents and data-room links are released only when current eligibility evidence is on file and there is no uncleared sanctions match. | AC-6, AC-9 |
| Who reviews access? | Administrators see every sign-in (time, IP address, device) and every switch-on, switch-off and role change, which are written to the access log. Monthly privileged-access reviews are recorded in the desk. | AC-2, LG-5 |
| How do server endpoints authenticate? | Each endpoint checks the caller's own sign-in token with the database, so the same role, two-factor and one-session rules apply, and counts each use against a daily limit. The hosting platform holds no database master key. | AC-8 |
| Account recovery? | An administrator verifies the person by calling back a number already on file, then sends a reset; the person re-enrols two-factor. A second administrator handles administrator accounts. | AC-1 |
2. Data protection and encryption
| Question | Answer | Control |
|---|---|---|
| Where is data stored? | In a Supabase project (managed Postgres database, authentication and file storage). Vercel serves the web pages and runs the server endpoints; it holds no desk records. | DP-2 |
| Encryption in transit? | HTTPS only. Browsers are told to refuse plain HTTP for two years (HSTS with preload). Connections to the database are over TLS. | DP-1 |
| Encryption at rest? | Database and file storage are encrypted at rest by Supabase (AES-256, per Supabase). Backups are encrypted by us before they leave the backup job. Mailbox connection tokens are encrypted (AES-256-GCM) before they reach the database. Vendor keys are kept as Vercel environment variables, never in the code. | DP-2, DP-3, DP-4 |
| How are bulk exports controlled? | Downloads, printing and large copies are locked for everyone by default. An administrator opens an export window (at most two hours); every export is recorded in the access log. Every screen carries a faint watermark with the user's email. Browser-side blocks are deterrents; the server-side limits are the control. | DP-5 |
| Rate limits? | Investor list reads are limited per user per minute, profile views and portal messages per day, and paid outside calls (phone, transcription, drafting) per person per day. Public forms use a hidden honeypot field, a small proof-of-work, and per-address and daily limits. | LG-4 |
| Web security headers? | Content-Security-Policy on every page, X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy no-referrer and a restrictive Permissions-Policy. Public pages allow only scripts we serve or have hashed, with no eval. | DP-6 |
| Known exception? | The desk app's policy must allow inline scripts and eval, because its runtime compiles the page in the browser. Displayed values are escaped and no user-supplied HTML is rendered. This is recorded as an accepted risk in our threat model. | DP-6 |
| How are secrets managed? | The database master key exists only as a GitHub Actions secret used by scheduled jobs. Every code change is scanned for committed keys. Keys have a written owner, location and yearly rotation, and rotations are logged. The browser key in the page is a public key by design; row-level security, not the key, protects data. | DP-7 |
| Sanctions screening? | Every investor and loaded contact name is checked against the U.S. Treasury OFAC SDN list every night. A possible match blocks allocation and document access until an administrator clears it with a reason, which is logged. | OP-3, AC-9 |
| Data retention and deletion? | The access log is kept for the period an administrator sets (default six years, with a minimum), and never while a legal hold is on. Deletion requests are handled as in the privacy notice, except where recordkeeping rules require us to keep a record. | LG-6 |
3. Logging and tamper evidence
| Question | Answer | Control |
|---|---|---|
| What is logged? | Sign-ins and sessions, page and record views, exports, blocked attempts, role and policy changes, eligibility and sanctions decisions, data-room grants, and closing-file exports. | LG-1, LG-5 |
| Can logs be altered? | The access log is append-only: the database refuses updates and deletes. Each row carries a SHA-256 hash of the previous row's hash and its own contents, so any edit or removal breaks the chain. The only deletion path is the retention purge, which records the chain head before and after. | LG-1, LG-6 |
| Is the log checked? | Every night the whole chain is recomputed. A broken chain, or anyone hitting a rate limit, turns the job red and emails the administrators. | LG-2 |
| Is there outside evidence of the log's state? | Yes. Each night the chain head is timestamped by an outside RFC 3161 timestamp authority and by OpenTimestamps. Only the hash is sent. Closing files include the chain segment and its timestamps, and can be checked offline with our closing file verifier. | LG-3 |
| Are staff identities exposed in shared files? | No. The log records a keyed pseudonym for each person alongside the email, and the chain is computed on the pseudonym, so a closing file can be shared without naming staff. | LG-1 |
| Are communications retained? | Desk messages, portal messages, emails sent from the desk, call transcripts and approved call notes are written to a write-once communications journal every night. Saved transcripts and approved notes cannot be changed. | BR-4 |
4. Backups and recovery
| Question | Answer | Control |
|---|---|---|
| How often are backups taken? | Every night, a full backup of every table and every data-room file, with a manifest of row counts and SHA-256 fingerprints. On weekdays an hourly incremental backup of changed rows runs from 7 am to 7 pm Eastern. | BR-1, BR-3 |
| Are backups encrypted? | Yes, before upload, to an offline owner key and a separate drill key. Plaintext exists only in a temporary folder during the job. | DP-3 |
| Are backups immutable? | When set up Backups go to object storage with Object Lock in compliance mode, so no one, including us, can change or delete them before the retention date. Until that bucket is configured, the encrypted backup is kept for 90 days as a private GitHub Actions artifact, which is not object-locked. | BR-1 |
| Are restores tested? | Every Sunday an automated drill takes the newest backup, checks its lock (where configured), decrypts it, checks every fingerprint and row count, loads it into a fresh database and checks it the way the app reads it. A failed drill turns red. | BR-2 |
| Recovery point? | About one hour during weekday working hours; otherwise the previous night's backup. | BR-1, BR-3 |
| Recovery time objective? | Not yet No formal target is set. The weekly drill shows a full restore works; its run time is recorded in the job log. | BR-2 |
| Second region or provider? | Not yet The backup job can write a second object-locked copy to another region or provider; this is not yet switched on. | BR-5 |
| Who holds the backup key? | The owner key is kept offline in two sealed copies held separately; the drill key lives only in the restore environment. Opening a sealed copy is treated as an incident and the key is rotated. | DP-7 |
| How is availability monitored? | The site and database are checked every 30 minutes, with a synthetic sign-in every six hours; results are public on the status page. The database is also kept active by a twice-daily job. | OP-1, BR-6 |
5. Development and change control
| Question | Answer | Control |
|---|---|---|
| How are changes tested? | Every pull request runs unit and feature tests, Python checks, data-quality checks, a scan for committed keys, a Content-Security-Policy drift check and a link check. Every production deploy also runs browser tests and loads the real database schema into a throwaway database to check, as each kind of account, what the server allows. | OP-2, AC-2 |
| Who can deploy? | Production deploys only from the main branch through the deploy workflow, which checks afterwards that production serves that exact commit. | OP-2 |
| Is there a threat model? | Yes, reviewed in October 2026 and yearly, or when a new outside source, endpoint or kind of user is added. | OP-4 |
| Are outside services least-privilege? | Each outside service (phone, transcription, drafting, mailbox) is off until its own key is set; until then the endpoint answers "not connected". Mailbox connections ask only for permission to send mail. | AC-8 |
6. Incident response and disclosure
| Question | Answer | Control |
|---|---|---|
| Is there an incident response plan? | Yes: a written security incident runbook, an incident log and a data-incident notice template, kept in the desk's settings. | IR-2 |
| Has the plan been exercised? | Not yet No tabletop exercise is on record yet. | IR-2 |
| How are customers told about an incident affecting their data? | [Notification commitment and timing to be confirmed by counsel and set in the subscription agreement.] | IR-2 |
| How can someone report a vulnerability? | Email security@securitief.com. We reply within two business days. Rules for good-faith research are on the security and privacy page, and a machine-readable security.txt is published. | IR-1 |
| What happens if a device is lost? | The user or an administrator signs the account out everywhere, then the password is changed. | AC-4 |
7. Subprocessors
Services that process data for us. Those marked "when connected" are off until a desk connects its own account, and receive data only for the feature that uses them.
| Provider | What it does | Data it receives | Status |
|---|---|---|---|
| Supabase | Database, sign-in and file storage | All desk and portal records, data-room files | Always |
| Vercel | Serves web pages; runs server endpoints | Requests passing through (IP address, request data); no stored desk records | Always |
| GitHub | Source code; scheduled jobs (backups, sanctions screening, data refresh) | Records in transit during jobs; encrypted backups until a backup bucket is set up | Always |
| Google Fonts | Font files for public pages and the desk | Visitor IP address and browser details | Always |
| unpkg (public script CDN) | Open-source script libraries the desk loads at sign-in | Visitor IP address and browser details | Always |
| Object storage provider [to be named] | Encrypted, object-locked backups | Encrypted backups only | When set up |
| Twilio | Desk calls and call recording | Phone numbers, call audio and recordings | When connected |
| OpenAI or Deepgram | Call transcription | Call audio | When connected |
| Anthropic | Drafting call notes and other desk writing tasks | Transcript or text the user submits | When connected |
| Google or Microsoft | Sending email from a firm's connected mailbox; optional sign-in | Outgoing messages and recipients; sign-in identity | When connected |
| Slack or Microsoft Teams | Team notifications of desk events | Short event messages | When connected |
| Email (SMTP) provider [to be named] | Alerts, digests, newsletter confirmations | Recipient addresses and message text | When connected |
| Communications archive vendor [to be named] | Copy of the communications journal | Journalled communications | When connected |
| IPinfo | Names the network a visiting IP address belongs to (site analytics) | Visitor IP address | When connected |
| Billing provider (for example Stripe) | Subscription billing | Billing contact and payment details | Not connected |
The outside timestamp services (an RFC 3161 authority and OpenTimestamps) receive only a hash, never records or personal information.
8. Certifications and testing
| Item | Status |
|---|---|
| SOC 2 Type I or Type II report | Not yet No SOC 2 audit has been performed. A readiness mapping of existing controls to the Trust Services Criteria is prepared and available on request. |
| Outside penetration test | Not yet No outside test has been performed. The scope (public site, desk, portal, server endpoints, database access rules and sign-in) is written and ready for a testing firm. |
| ISO 27001 | Not yet Not certified. |
| Automated access-rule tests | In place Run before every production deploy against the real database schema. |
| Vendor security reviews | In place Vendor questionnaires are recorded in the desk. |
| Cyber insurance | [To be confirmed.] |
| Staff background checks and security training | Training completions are recorded in the desk. [Background-check policy to be confirmed.] |
Control references (AC, DP, LG, BR, OP, IR) match our internal control list, which maps each one to where it is implemented. Updated October 2026. See also: security and privacy, privacy notice, terms of use (draft).