Permissioning that holds at the API, not just the screen

What SOC 2 Type II compliance actually covers

A SOC 2 Type II examination is not a certificate. It is an independent auditor's opinion on whether a described set of controls was suitably designed and operated effectively across a period of time. In this case a full twelve months, not a snapshot in a single week.

Thoropass Assurance examined SEAD's controls against the Trust Services Criteria for Security and Availability across the period January 1 to December 31, 2025, and issued an unmodified opinion: that the system description was presented fairly, that the controls were suitably designed, and that they operated effectively throughout.

AWS is a carved-out subservice organization. Their own controls were not examined here; the report identifies what is expected of them, and we review their attestation annually.

Requesting the report

The report is confidential and restricted-use. It carries an explicit limitation on who may rely on it, and every page is marked accordingly. We share it under NDA with prospective and existing clients, their advisors, and others who fall within the audience the report names. Ask your account contact, or raise it in a first conversation, and we'll start the paperwork the same day.

Row and column-level permissioning

In a conventional BI stack, restricting a user to their own region is a project. Columns have to be named consistently across every source. Assignments are maintained by hand. And if the same data is reachable by API, the whole permission layer has to be written a second time for that path.

Co-Wright inverts it. Filters are declared on the table.

• An entity-level filter restricts which rows a given group can see.
• A field-level filter restricts a specific column.

Both are set once, on the schema. Every dashboard, list, form and API endpoint that reads that table inherits them.

It does it at the API layer. It's not pulling all the data and then filtering on the front end. It's actually restricting the access at the API level.

Eric WrightChief Technology Officer

The consequence matters more than the mechanism. Build a new list, a new form, a new dashboard against that data six months later, and the filter is already applied. Nobody has to remember to scope it.

The same holds for machine access. An API account is assigned to a tenant and issued a token. When it calls the generated endpoints, it gets the filtered result: the same rows a human in that tenant would see, enforced in the same place.

The access model

Three concepts, in order of containment.

Individual users can then be extended, granted additional access on top of what they inherit, or overridden, replacing the inherited set entirely.

You get the high-level group policy, and you get the ability to override it.

Eric WrightChief Technology Officer

Authentication

Authentication methods are set per user, under Administration. Single sign-on can be enforced at workspace level, so a user never holds a separate Co-Wright credential at all. Where local credentials are used, password configuration is enforced against SEAD's Password Policy.

Sessions terminate automatically after15 minutes of inactivity. This was built for customers handling protected health information, where an unattended workstation is the exposure.

Audit and lineage

When auditing is enabled on a table, Co-Wright creates a parallelaudit schema mirroring it, and writes every transaction against it: insert, update, delete.

Two modes:

System time records every change to every column.Business time records only when nominated fields change, such as name, address or industry, for cases where the full stream is noise.

Audit tables are archived on a schedule so history stays reachable.

Separately, soft deletion can be enabled. Records carrycreated_at,updated_at anddeleted_at metadata; deleting through the interface stamps deleted_at rather than removing the row, leaving it restorable or permanently deletable as a deliberate second act.

Two more safeguards sit above that:

• Safe delete requires typing the word to confirm, not just clicking through a dialog.
• Business specs are cloned on deletion. Restoring is one action; removing the clone requires a second explicit delete.

And business specs are version controlled. A change that introduces a bug is a few clicks from being rolled back or forked, the way a branch is.

Our infrastructure

Access to the AWS console runs through Microsoft single sign-on, governed by security groups on the Microsoft side, with two-factor enforced there. This replaced direct IAM users with two-factor and passkeys, which are being retired.

Reaching a production server is a further step. Terminals sit behind an encrypted an enterprise grade VPN tunnel, itself gated by Microsoft SSO, with its own access controls determining who reaches which host.

Credentials for partner environments are held inan enterprise grade password vault. Developer IAM access keys are rotated periodically.

In order to even access the terminals for a lot of these servers, you have to authenticate through our Identity Provider (IdP) and install the VPN client to connect.

Kevin MauldinHead of Infrastructure

Resilience

The production database cluster runs on RDS in multi-AZconfiguration, across a read-write instance and a read-only replica. If an availability zone fails, failover to the other is automatic.

Beyond the region, data replicates to a second region, Virginia to Ohio. S3 buckets holding record attachments and bundles replicate the same way, with versioning enabled, so an object deleted or overwritten in error can be rolled back.

Backups run nightly for the database and for production EC2 instances, and restoration is tested annually.

If one availability zone goes down, it automatically switches over to the other one.

Kevin MauldinHead of Infrastructure

Encryption

Customer data stores are encrypted at rest, using AWS-managed keys. EC2 volumes are encrypted as well, though they hold no customer data. Data in transit over public networks is encrypted by secure transport protocols.

How changes reach production

No single person ships to production. Branch protection rules in the development tool enforce review before merge, and every release is tested by the team in a preview environment separate from production before approval.

Regression testing is increasingly automated, using Playwright driven by AI agents, which has substantially reduced the small-bug class of release defect.

It's basically doing regression testing for us, so we don't have to do that manually anymore.

Kevin MauldinHead of Infrastructure

What we don't claim

We would rather be the vendor whose security page you didn't have to fact-check.

• The report coversSecurity and Availability. Not Confidentiality, Processing Integrity or Privacy.
• Multi-tenancy is not yet audited.It shipped after the audit period and enters scope this December.
• Cross-region recovery is manual, at roughly an hour.
• AWS's own controls were not examinedby this report. We review their attestation annually.
• One access group per tenanttoday.
• No HIPAA certification, because none exists — there is no formal audit.
• The report isconfidential and restricted-use, so we don't publish it or summarize its findings here. We share it under NDA and expect you to read it closely.

Your data is secure, encrypted, and accessible to the level of which you're granted access to from the platform.

Alexander WrightPresident & CEO