How we protect your records.
Inspection records are legal documents. Here is how we keep them isolated, tamper-evident, and recoverable — in the plain terms your team needs. A detailed technical security overview is available to your security team on request.
Your data is separated at the database, not just the screen.
Separation on every path
Access rules are enforced by the database itself, so they apply on every path by default rather than depending on the interface. A query that omits a tenant filter returns nothing — never another company’s data.
A backstop that cannot be overridden
A restrictive layer sits underneath every rule, so even a mistaken permissive setting cannot let one company’s data cross into another’s.
The browser holds almost nothing
The key delivered to the browser has essentially no direct access to data. Every request is authorized against the signed-in person’s own permissions.
Unknown workspaces are refused
A request for a workspace that was never set up is turned away before the application loads at all.
A released report cannot be quietly changed.
Locked at the data layer
Once a report is approved or released, it is locked by the database itself — not by hiding a button. An attempt to alter a released report is refused outright.
Corrections are tracked, not silent
Changes after release go through a tracked revision workflow that preserves the original version, so the record always shows what it said when it was issued.
Important changes are recorded automatically
Releases, signatures, access and role changes, and deletions are logged by the database rather than by application code that could be skipped. A deletion records its entry before it happens, so evidence cannot be removed by the same action.
A record of who did what — that nobody can edit.
Append-only, even for administrators
The audit, sign-in, and access logs can be read but not changed. No signed-in account — yours, ours, or an administrator’s — can edit or delete a log entry. Only server-side processes add to them.
Scoped to each company
A company administrator sees their own company’s records and no one else’s.
Roles, money, and sessions.
Role-based, enforced in the database
Access follows a person’s role and is enforced at the data layer, not just the screen. Billing access is separate, so seeing invoices does not grant project access.
Financials gated separately
Seeing a project does not mean seeing what it is worth. Financial and payroll visibility are granted separately and are not part of ordinary project access.
Sessions expire; sign-in is protected
Sessions end automatically, with shorter idle limits on more sensitive surfaces. Password sign-in is rate-limited and temporarily locks after repeated failures. Single sign-on through your own identity provider is supported.
The part of the system strangers can reach — hardened accordingly.
Access codes are never stored
We keep only a strong one-way hash of a portal code. If a client loses it we issue a new one, because no one — including us — can recover the old one.
Guessing is stopped, and it fails closed
A bot check and rate limiting run before any code is checked, and if a limit cannot be evaluated the system treats it as reached rather than open.
The form reveals nothing
A wrong code and a project that does not exist produce the same response, so the sign-in form cannot be used to discover whether a project exists.
Addresses are hashed, not stored
Access attempts are recorded against a one-way hash of the visitor’s network address — the address itself is never written down.
Security is managed as an ongoing business process.
Technical safeguards matter most when they are backed by repeatable review, ownership, and release discipline.
Vulnerability management
Automated dependency, code, configuration, and application checks run through the guarded release workflow. Security-relevant findings are tracked through remediation and re-verification before they are closed.
Risk management
Security and operational risks are recorded with severity, treatment, evidence, and status. Higher-impact risks can block a release until they are addressed or formally accepted through the review process.
Change management
Production changes move through version control, automated tests, review gates, and traceable build identifiers. Post-deployment checks confirm that the approved build is the one operating in production.
We attack it before anyone else can.
Regular penetration testing
Every security-relevant change is attacked before it ships, by a reviewer separate from the person who wrote it — real attempts against the running system, such as forging requests, crossing tenant boundaries, and probing sign-in and the portal. What we find is fixed and re-verified against production.
A release path that cannot be bypassed
Code cannot reach production without passing automated security and isolation checks, and the release path cannot be skipped — including by an administrator.
Dependencies watched every release
Each release checks our software dependencies for known vulnerabilities and blocks on anything serious, so a known weakness in a third-party library cannot quietly ship.
What we never hold, and where it runs.
No card or bank details, ever
The platform never collects payment credentials on any screen. Card entry happens on the payment processor’s own hosted pages; we keep only remit-to details for invoicing.
Transport and browser hardening you can verify
HTTPS is enforced with HSTS; a strict Content-Security-Policy limits what the browser may load and forbids the site being framed; MIME-sniffing is off and referrer and device-permission policies are restrictive. These are visible in the response headers.
Established cloud infrastructure
The platform runs on established cloud infrastructure providers, with encryption in transit and at rest and regular backups that are restore-tested.
What security and IT teams usually ask.
Clear answers about access, separation, account protection, and security review.
Is my company’s data secure?
Inspections Manager is designed with layered safeguards: encryption in transit and at rest, database-enforced tenant isolation, role-based access, protected file paths, append-only audit records, guarded releases, and continuous security checks. No internet-connected service can promise zero risk, so these controls are tested and improved as the product changes.
Can another company see our projects or reports?
Tenant separation is enforced at the data and file layers, not only by what the interface displays. Requests are evaluated against the signed-in person, company, role, and the specific record or object being requested.
Who inside Inspections Manager can access customer data?
No one at Inspections Manager can access customer operational or private data without explicit authorization from an administrator of that customer company. Some software providers rely on internal “need-to-know” permissions for employee access; Inspections Manager does not treat an internal permission as sufficient—the customer administrator controls whether support access is granted. When access is required for a specific support need, it is limited to the approved purpose and expires automatically. The authorization, approval, expiration, and revocation are recorded in an auditable access history.
How are accounts protected?
Administrative access requires multi-factor authentication. Password sign-in is rate-limited, sessions expire, sensitive permissions are checked at the data layer, and enterprise customers can use single sign-on through their identity provider.
What happens after a report is released?
The released record is locked at the data layer. A later correction must use the revision workflow, preserving the previously issued version and the history of what changed.
How do you find and fix vulnerabilities?
Security-relevant changes receive adversarial review and automated checks for application behavior, tenant boundaries, database authorization, dependencies, and release integrity. Findings are remediated, re-tested, and verified against the running service before closure.
What can our security or legal team review?
On request, we provide a deeper security overview, the Data Processing Addendum, sub-processor information, and commercially reasonable answers to security questionnaires. Public privacy, terms, accessibility, and security information is available from the Legal Center.
How do I report a security concern?
Email security@inspectionsmanager.com with a description of the concern and enough information for us to reproduce it. Please do not include passwords, access codes, or customer records in the initial message.
Need a deeper security review?
Enterprise customers and their security teams can request our full security overview, sub-processor list, and Data Processing Addendum as part of a security review. To report a security concern, contact security@inspectionsmanager.com.
Request the security package