Is Compliance Software Secure Enough for Building Records?

Building inspection records are sensitive. They include client floor plans, equipment serial numbers, photos of life safety systems, technician credentials, certificates of insurance, and audit trails that AHJs rely on during enforcement. If that data leaks, gets ransomed, or simply vanishes when a vendor shuts down, the consequences are not abstract — they are operational, legal, and reputational. So the question is not whether compliance software is secure in general, but whether it is secure enough for the specific records your business depends on. Here is how to evaluate a vendor honestly.

What Secure Enough Actually Means for Building Records

Security is a stack of controls, not a single feature. For compliance software, secure enough means: the vendor has been audited by an independent third party (SOC 2 or equivalent), customer data is encrypted both at rest and in transit, access is controlled by role and audited, the data is portable so you are not locked in if the vendor disappears, and the vendor has an incident response plan they can actually describe. Any vendor missing one of these is not a serious candidate for storing your building records. Vendors who cannot describe their controls in concrete terms are usually winging it.

SOC 2 Compliance: The Baseline, Not the Ceiling

SOC 2 is the de facto standard for SaaS security in 2026. It is an independent audit against five trust principles: security, availability, processing integrity, confidentiality, and privacy. There are two types — Type 1 confirms that controls exist on a specific date, Type 2 confirms they have been operating effectively over a six to 12 month period. Type 2 is the meaningful one.

Ask every vendor for a current SOC 2 Type 2 report under NDA. If they cannot produce one, they are either too small to have invested in compliance or they failed an audit. Either is a red flag. SOC 2 is the baseline, not proof of perfection — but its absence is a strong signal to walk away.

Encryption at Rest and in Transit

All customer data should be encrypted in transit over TLS 1.2 or higher, with HSTS enforced and weak ciphers disabled. At rest, data should be encrypted using AES-256 or stronger, with keys managed by a cloud KMS (AWS KMS, Google Cloud KMS, or Azure Key Vault) and rotated on a documented schedule. Photos and uploaded documents should also be encrypted at rest in object storage, not stored in cleartext.

Ask vendors specifically: what is the encryption algorithm for data at rest, who controls the keys, and how often are they rotated? Vague answers like "we use bank-grade encryption" are marketing, not security. A serious vendor can answer in three sentences.

Access Controls and the Principle of Least Privilege

Inside the software, access controls determine who can see what. The vendor should support role-based access control (admin, technician, client) with permissions enforced on the backend, not just hidden in the UI. Multi-factor authentication should be available for all users and required for admins. Single sign-on (SAML or OIDC) should be available on business and enterprise tiers.

On the vendor side, look for principle-of-least-privilege internally: vendor employees should not be able to read customer data without a documented break-glass procedure that gets audited. Ask: can your engineers see our data? The honest answer is some employees can in narrow, audited circumstances. Vendors who claim "no, never" are usually misrepresenting how their support team actually operates.

Data Residency and Tenant Isolation

Most compliance software runs in shared multi-tenant infrastructure — your data lives in the same database as everyone else, separated by tenant ID. This is fine if the isolation is enforced rigorously at the application and database layer. Ask: how is multi-tenant data isolated? A good answer describes both row-level isolation (every query is filtered by tenant ID) and access policies that prevent cross-tenant reads even if a bug slips through. For larger customers, some vendors offer dedicated database instances or single-tenant deployments at a premium.

Data residency matters less for compliance software than for healthcare or finance, but if your contracts or insurance carriers require US-only hosting, confirm the vendor primary region and backup region in writing.

What Happens if the Vendor Shuts Down

This is the question most buyers forget to ask. If the vendor goes bankrupt, gets acquired and shut down, or simply fails to renew their hosting contract, what happens to your data? A serious vendor offers two guarantees: data export at any time in standard formats (CSV, JSON, PDF), and a documented wind-down procedure that gives customers a minimum window — usually 60 to 90 days — to extract their records before service ends.

Ask for the export endpoints in writing. Test them during the trial: export your inspection data, client list, and equipment inventory, and confirm the export is complete and usable. If the vendor charges for exports or makes them slow and painful, that is a hostage situation in slow motion. Walk away.

How to Evaluate a Vendor Security Posture

Before signing, request five documents: a current SOC 2 Type 2 report (under NDA), a security whitepaper describing encryption, access controls, and infrastructure, the data processing addendum (DPA) for contractual security commitments, the incident response plan summary, and a sample data export to verify portability. Cross-reference what the documents say with what the sales team says — they should match.

Ask one technical question that is hard to fake: how do you handle a critical CVE in a dependency that affects production? A serious vendor can describe their vulnerability management process, patch cadence, and how customers are notified. A vendor who hand-waves the answer either does not have a process or is not telling you about it. Either way, the answer is informative.

Compliance software security is not a feature you buy — it is a posture you evaluate. SOC 2 Type 2, real encryption, sane access controls, multi-tenant isolation, and a credible wind-down plan are the minimum bar. Anything less and your building records are at risk in ways no marketing page will admit. KomplyOS is built with these requirements in mind: encryption at rest with managed keys, role-based access controls enforced on the backend, tenant isolation at every query, and full data portability so you are never locked in.