Technical security details
Cryptography, identity, audit trail and data flows, for the people who sign off.
This page is for the person who has to sign off on Inspection Hero: the security architect, the ISSO, the CJIS coordinator, the procurement analyst working through a questionnaire. It names every mechanism in the shipped iPhone, iPad and Mac app, with parameters, and draws the boundaries plainly. Read it with the Privacy Policy, which is the binding statement of what the app does with data, and Security, which is the shorter version for everyone else.
One sentence of architecture makes most of the rest follow: Inspection Hero has no server of ours anywhere in the path. Records live in a database on each device and, when your organization chooses, move between devices through storage your organization operates. We never receive, process, or store customer data, and the app contains no telemetry, analytics, crash reporting, license check, or update check that reaches us.
1. Every network destination the app can contact
A fresh install with nothing configured makes no network connections at all. Each row below is an integration a Supervisor or Integrations Admin turns on, pointing at a service your organization already controls. Nothing in this table is us.
| Destination | When | What is sent | Controlled by |
|---|---|---|---|
| Your Data Sync storage: Amazon S3, an S3-compatible store, Google Cloud Storage, Azure Blob Storage, Azure Files, or a REST endpoint you host | On sync, while the app is open or on demand, and when iOS runs the app in the background (a pull) | Inspection records, checklist answers, comments, media metadata and files, account records without passwords, signing public keys, the inspection audit trail, schedules with a copy of their checklist, the organization’s branding, AI policy and Single Sign-On settings, the due-alert record, on Team plans the license objects in section 6, and, when a destination is saved, one small connection-check file (device identifier and time) | Your organization |
| Your identity provider | At Single Sign-On, and when Test connection is tapped (section 5) | An OpenID Connect authorization request; the app receives an ID token. Sign-in and Test connection read the provider’s public configuration and signing keys | Your organization |
| Slack, Microsoft Teams, Discord, Telegram, a generic webhook, or email through a Gmail / Microsoft 365 mailbox or your own SMTP relay | When a due or overdue alert fires, from the open app or the background run in section 2 | The alert text: inspection title, site, status, due date | Your organization |
| The same destinations, for workflow events, from each device an Integrations Admin turns them on for | When, on that device, an inspection is submitted, reviewed, approved, sent back or reopened, an item fails critically, or a failed item’s follow-up is closed; an event still waiting to be delivered can also go out from the background run in section 2 | The inspection’s title, site, template, status, score and due date; the name and role of the person who took the step; item counts; up to 25 failed items with notes and follow-up owner names; the signing key’s identifier and the record’s fingerprint. Never photos, signatures or email addresses | Your organization |
| The AI endpoint you configure, including a model on your own network | Only after a Supervisor turns AI on and the person allows that service, only when they tap Generate, Organize with AI, Suggest, Draft, Draft from photo, Fill by voice or Test connection, and only when the organization’s AI route sends that request to the key (never under “Only on this device”) | What that action needs: a checklist description; text read on the device from a scanned, photographed or PDF checklist, after review (never the image or file); one item’s label, type, status, value and notes; what the person typed or said for Fill by voice; a photo the person picks for Draft from photo; an inspection’s title, site, area, template name and item results for a description, summary or insights, with earlier inspections at the same site for a summary or insights; or a template’s name, description and items. Test connection sends a short test message and a small test image, never inspection data. Follow-up owners are never sent | Your organization |
| Google Static Maps or Mapbox, only if you enter a key | At report export, and when an inspection with a site location is opened | The GPS coordinates of each geotagged photo in that report, or the site’s coordinates and radius | Your organization |
| Apple Maps, only if chosen as the map source | At report export, and when an inspection with a site location is opened | A request for the map around those same coordinates; the map is drawn on the device | Apple, under your devices’ existing Apple relationship |
| Apple WeatherKit | Only when weather is turned on in Settings and an inspector taps “Get current weather” | One coordinate; the answer is written into the inspection as plain text | Apple, under your devices’ existing Apple relationship |
| Inspection Hero | Never | Nothing | — |
Drafts made with Apple Intelligence are not in this table because they make no connection. Inspection Hero works with Apple Intelligence on supported iPhone, iPad and Mac (iOS, iPadOS or macOS 26 or later, with Apple Intelligence turned on, for requests in English). A draft made with it runs through Apple’s Foundation Models framework on the device: the request and the draft never leave it, and no permission is asked. The model is part of the operating system, which downloads and updates it; the app never does. A Supervisor chooses where AI runs (your AI key first, on the device first, or only on the device), and the choice syncs to every device in the organization.
Every connection the app initiates is HTTPS. The app refuses to save a plain http:// Data Sync, identity-provider or webhook address for any host other than the device itself, and warns when an AI endpoint is unencrypted. Transport security is the operating system’s: iOS App Transport Security, TLS 1.2 or later, certificate validation against the device’s trust store. A store on a closed network under your own certificate authority works once that authority’s root is trusted on the device, which your MDM can install. The app pins no certificates, so an inspecting proxy your organization trusts on the device is honored rather than broken.
Updates arrive through the App Store, so your MDM decides when they install. The app never downloads code or configuration from anywhere.
2. Platform
- Distribution. iPhone, iPad and Mac, from the App Store, under Apple’s code signing and review. Deploy it through Apple Business Manager and your MDM like any other App Store app. Android: coming soon.
- Isolation. The app runs in the iOS app sandbox. Its database, media files and generated reports live in the app container and are covered by iOS Data Protection, so they are encrypted at rest under the device passcode by the operating system’s validated cryptography.
- Secrets. Every credential the app holds — storage keys, SAS tokens, bearer tokens, webhook URLs and bot tokens, mailbox refresh tokens, the email relay password, AI and map API keys, the backup-signing secret, and each account’s sealed signing key — is a separate item in the iOS Keychain. Alert destination credentials, the mailbox refresh token and the Data Sync key can be read once the device has been unlocked after a restart, so the background run can send alerts and pull changes with the phone locked; every other item can be read only while the device is unlocked. None of them is in the database, in a plain backup, or on the wire.
- Permissions. Camera, microphone and photo library, used only to attach evidence to checklist items. Location, used only at the moment a photo is taken and for the site geofence check; there is no background location. Local notifications for due-date reminders and notices about new work, scheduled and delivered by iOS on the device: the app has no push entitlement and talks to no notification service. One background mode, iOS background processing: iOS runs it when it chooses, to create the day’s scheduled inspections, send due alerts and waiting workflow events, pull other devices’ changes from Data Sync storage for up to 20 seconds (it sends nothing to that storage and downloads no media), and show the person who last used the device a notice about new work that names nothing. A background launch runs no full sync and does not count as activity for the idle sign-out; both wait for someone to open the app. A notice names an inspection only when it appears while the app is in use. It never reads location and does nothing in the demo.
- Two databases. The built-in demo runs in its own database file, seeded from data about a fictitious company, and never syncs; real work lives in a separate file. Exiting the demo deletes its database.
3. Cryptography inventory
| Purpose | Algorithm | Parameters | Where it runs |
|---|---|---|---|
| Account passwords | PBKDF2-HMAC-SHA-256 | 120,000 iterations, random per-account salt, 256-bit output; never stored in plain text | Apple CommonCrypto on the device, off the JavaScript thread |
| Sealing each account’s signing key | AES-256-GCM under a PBKDF2-HMAC-SHA-256 wrapping key | Wrapping key derived from the account password with its own purpose-prefixed salt; sealed blob in the Keychain. An account with no password (Single Sign-On only) uses a random per-device secret in the Keychain instead | Application code |
| Workflow signatures: submit, review, approve, request changes, reopen | Ed25519 over a SHA-256 digest | One key pair per account per device; canonical JSON of the record’s content columns, items, media and comments | Application code; verified on every device and on the report |
| Record fingerprint on the certification page | SHA-256 | Digest of the canonical signed envelope | Application code |
| Media and drawn-signature integrity | SHA-256 content addressing | Every file is stored and referenced by the hash of its bytes; a download that does not match is rejected | Application code |
| Backup integrity | HMAC-SHA-256 | Random per-install secret held in the Keychain, over the exact exported bytes | Application code |
| Encrypted backups | AES-256-GCM with a scrypt-derived key | scrypt N = 2¹⁶, r = 8, p = 1, 128-bit salt, passphrase of at least 15 characters, NFKC-normalized | Application code |
| Setup links: settings handed to the next device | AES-256-GCM with a scrypt-derived key | scrypt N = 2¹⁶, r = 8, p = 1, 128-bit salt, from a 10-character setup code (50 bits) shown only on the originating device and never in the link; version, salt and nonce authenticated with the payload; opens for 24 hours | Application code |
| License keys | Ed25519 | 64-byte signature over the token; issuer public keys pinned in the app | Verified on the device; no network |
| License-usage records in your storage | AES-256-GCM; SHA-256 one-way hashes of account emails | Key derived by SHA-256 from your license key, so only devices holding the license can read them | Application code |
| Amazon S3, S3-compatible and Google Cloud Storage requests | AWS Signature Version 4 (HMAC-SHA-256) | Verified in CI against Amazon’s published test vectors | Application code |
| Azure Blob Storage and Azure Files requests | Container or share SAS | The app signs nothing; the SAS you generate carries the permissions and expiry | Your Azure account |
| Single Sign-On | OpenID Connect authorization code with PKCE (S256); ID token RSASSA-PKCS1-v1_5 with SHA-256 | Issuer, audience, expiry and nonce checked; provider signing keys fetched over HTTPS from the issuer’s discovery document; no client secret in the app | Application code; the sign-in itself runs in the operating system’s authentication session |
| Outbound webhooks | HMAC-SHA-256 with your signing secret | X-Inspection-Hero-Signature: sha256=… over the exact JSON body; the app can generate the secret. X-Inspection-Hero-Event and X-Inspection-Hero-Delivery name the event and its delivery id, so a receiver can drop a repeat | Application code |
| Random values: salts, nonces, secrets, identifiers | Operating-system CSPRNG | SecRandomCopyBytes; the app refuses to fall back to a non-cryptographic source | iOS |
| Transport | TLS 1.2 or later | App Transport Security defaults; system trust store | iOS |
Application-code cryptography uses the noble libraries (@noble/hashes, @noble/curves, @noble/ciphers): independently audited, open-source, constant-time implementations with no native dependencies, which is what lets the same bytes verify on every device. The complete list of components and licenses ships inside the app under Settings → Legal → Open Source Licenses.
4. FIPS 140 status
The straight answer, because the question is always asked.
Validated modules. Apple’s corecrypto modules hold FIPS 140-3 validations for iOS and iPadOS; the certificate numbers vary by OS release and are listed on Apple’s platform certifications page. Inside Inspection Hero, the following run through those modules: password hashing (PBKDF2 via CommonCrypto), all TLS connections, iOS Data Protection over the database and files, the Keychain, Face ID and Touch ID through the Secure Enclave, and random-number generation.
Not validated. The application-code cryptography in section 3 — workflow signatures, sealed signing keys, encrypted backups, license verification, license-usage records, storage request signing, ID token verification, webhook signatures and content hashes — is implemented in software that has not been submitted for FIPS 140 validation. Its algorithms are NIST-approved (AES-GCM under SP 800-38D, SHA-256 under FIPS 180-4, HMAC under FIPS 198-1, PBKDF2 under SP 800-132, Ed25519 under FIPS 186-5, RSASSA-PKCS1-v1_5 under FIPS 186-5), with one exception: scrypt, used only to derive the key for an optional passphrase-protected backup, is specified in RFC 7914 and is not a NIST-approved key-derivation function. That is a deliberate choice. A passphrase-protected backup can carry every account’s password hash and every integration credential, so its passphrase is guarded by a memory-hard function that resists guessing on specialized hardware. Substituting PBKDF2 would not change the validation status of this layer.
What that means for a policy that requires validated cryptography. Data at rest on the device is protected by iOS Data Protection, which is validated; the app’s own encryption sits on top of it. Data in transit is protected by iOS TLS, which is validated. What the app adds — signatures that make a record tamper-evident, and encrypted backups — is additional assurance rather than the layer your policy relies on. A policy that requires validated implementations for every cryptographic operation, such as CJIS Security Policy 5.10 for criminal-justice information encrypted outside the operating system’s protection, should treat the encrypted backup and the signature layer as non-validated and rely on the platform layers for compliance. We are glad to go through this mapping with your assessor.
5. Identity, authentication and sessions
Local accounts. Accounts are created on the device by your own Supervisor. Passwords are at least 8 characters, hashed as in section 3, and never leave the device: not in Data Sync, not in a plain backup. Five failed sign-ins lock that account for five minutes.
Session policy. The signed-in session locks after 15 minutes without activity and requires re-authentication once an hour regardless of activity. Both are measured on the device clock, because there is no server to expire a token, and both are checked on every read of the active user, so a force-quit and relaunch cannot skip them. Unlocking takes the account password or, where the user has turned it on, Face ID or Touch ID.
Biometrics. Face ID and Touch ID go through the iOS LocalAuthentication framework with device-passcode fallback disabled and the strong biometric class required. A biometric resume never unlocks a password account’s signing key: after a cold launch or a biometric resume, signing a workflow step or an item signature requires the account password once. On a shared iPad that is what binds a signature to a person rather than to whoever is holding the device. An account with no password (Single Sign-On only) has its key sealed under a random per-device secret instead, and the identity provider’s sign-in is what binds it to the person; after a Face ID or Touch ID resume, such an account signs with no further prompt.
Single Sign-On. Any OpenID Connect provider — Google Workspace, Microsoft Entra ID, Okta, OneLogin, Ping Identity, or one you run on your own network — over the authorization-code flow with PKCE. The sign-in itself happens in the operating system’s authentication session, never in an embedded web view. The app verifies the returned ID token on the device: signature against the provider’s published keys, issuer, audience, expiry, and a per-request nonce against replay. An allowed sign-in domain list refuses identities outside your organization before any account exists. Multi-factor authentication is whatever your provider enforces; the app never sees a password for an SSO account and stores none.
One record for the organization. The Single Sign-On settings (provider, issuer, client ID, allowed domains, groups claim, role mappings, default role and the admins-only switch below) are one record that only a Supervisor saves. Once Data Sync is on, only a Supervisor whose own account belongs to the organization can save it, after the device has synced once. The record reaches every device through Data Sync, the newest save winning, and none of its fields is a secret. A device joining an organization takes the organization’s record and drops any settings of its own.
Test connection. Before anyone signs in, Test connection checks the values on the form, saved or not, against the provider’s public OpenID Connect configuration and signing keys: that the provider can be reached; that the issuer it names matches the one entered (for Microsoft Entra ID, the tenant too); that its sign-in endpoints are HTTPS; that its published configuration does not rule out PKCE (S256) or RS256-signed ID tokens, with at least one RSA signing key; and, as warnings where the provider publishes what they depend on, a missing groups scope when roles come from groups, or a missing auth_time claim (not checked for Google). An issuer that is not HTTPS, or a multi-tenant Entra endpoint, is refused before anything is fetched. Nothing is signed in and no account is needed; the client ID and redirect URI are checked at the first real sign-in.
Admins sign in with Single Sign-On only. A Supervisor can require that admin-tier accounts (Supervisor, Team Admin, Integrations Admin, Auditor) sign in only through the identity provider, so no password set on any device can stand in for one. Only a Supervisor whose own account signs in through the provider can turn it on, and it is in force only while a provider is configured and the plan includes Single Sign-On: if the plan stops including it (a lapse past the grace period, or Team + Single Sign-On renewed as Team), admins sign in with their passwords again until it does, and the SSO and License screens say so, with a heads-up during the grace period. Other accounts keep password sign-in.
Roles from your directory. Map provider groups to roles once and each person’s role and reviewer/approver flags follow group membership at every sign-in. Accounts managed that way are marked as such and cannot be edited locally; the directory is the source of truth.
Roles. Six, enforced in the storage layer rather than only in the interface:
| Role | Field records | People | Integrations and settings | Backups |
|---|---|---|---|---|
| Inspector | Create, edit, submit | — | — | — |
| Viewer | Read only | — | — | — |
| Auditor | Read only | — | — | Export, never restore |
| Integrations Admin | — | — | Data Sync, notifications, AI, maps | — |
| Team Admin | — | Manage Inspector, Viewer and Auditor accounts | — | — |
| Supervisor | Everything an Inspector can | Everything, including granting admin-tier roles | Everything | Export and restore; the only role whose encrypted export carries credentials |
Reviewer and approver are flags independent of role. No one can review or approve a record they submitted. Only a Supervisor can grant an admin-tier role, including to themselves, and a device’s last Supervisor cannot be demoted, so an install can never be left without an administrator. Single Sign-On, branding and the organization’s AI policy are a Supervisor’s alone.
6. Data at rest
On the device. One SQLite database per install mode inside the app container, plus media files stored by content hash, all under iOS Data Protection. Deleting a record removes it from the database; uninstalling the app, or a factory reset from Settings → Backup, removes the databases and every Keychain item the app created.
In your storage. Data Sync writes the following objects to the bucket, container or endpoint you configure, under a prefix per organization:
- An append-only, per-device record of changes, and periodically a full copy of the synced tables, as JSON: inspections, checklist items and answers, comments, media metadata including GPS coordinates where present, account records (name, email, role, flags, sign-in provider; never a password or hash), the public half of each account’s signing keys, the audit events for inspections, items, media and comments, and schedules, each carrying a copy of its template’s name, version and items, since templates themselves do not sync.
- Media files — photos, video, audio, drawn signatures — each stored whole under the SHA-256 hash of its bytes, up to 5 GB per file (one upload per file, the ceiling the storage services share); a larger file stays on the device that captured it, and a small marker records its size, type and when it was kept, so other devices show it as kept there. An administrator can hold files above a size of their choosing until the device is on Wi-Fi; the records sync regardless.
- The organization’s shared settings, each one record that the newest save replaces whole: branding (the report letterhead: name, logos, colors and typeface), the AI policy (whether the AI Assistant runs, whether personal keys may stand in for the organization’s, and where AI runs), and the Single Sign-On settings of section 5. None of them holds a secret.
- The due-alert record: for each alert destination, which inspections and follow-ups it was alerted about and when, so a second device set up for the same destination does not repeat an alert within 24 hours. A destination appears there only as a one-way hash, never as its address, token or recipients, and entries older than a week are dropped.
- On Team plans and above, a copy of the license key and one small encrypted license-usage record per device (section 3).
- One small connection-check file per device, written when a destination is saved and overwritten on each later save: the device identifier and the time. Saving reads it back, so a wrong credential is refused before it is stored.
These objects are stored as the app writes them. Encryption at rest, access control, logging, versioning, retention and residency are those of your storage service, and they apply because it is your storage: the app authenticates with credentials you issue and can be scoped to one bucket. A device arriving on the connection downloads the full copy first, then only changes. Templates never sync (a schedule carries its own copy of the checklist); every other setting stays on its device; secrets never sync.
Between your devices. A Supervisor or Integrations Admin can hand the sync destination and, if chosen, the alert, team AI key, maps and Smart defaults settings to another device as a setup link: one QR code per setting that the other device’s Camera opens, or all of them as one link shared through an app of your choosing. The settings and their credentials travel only inside the AES-256-GCM envelope of section 3, under a setup code shown on the originating device and typed on the receiving one; the code is never part of the link, the link opens for 24 hours, and applying it goes through the same role and plan checks as entering the settings by hand, except that a new install with no accounts can save the first code’s sync destination and join (below). Inside an organization, Single Sign-On is not carried in a setup link: it is the organization’s record and arrives with the first sync. Before a device joins an organization, it can still pass its own Single Sign-On settings in the link. Nothing passes through us.
Joining from a fresh install. On a new install, once the person chooses Set up for real work, the screen that offers to create the first inspector also offers Joining your organization?: open the first code’s link from the Camera, or paste it, and type the setup code. The device checks the storage, refusing storage no organization has synced to before anything is saved, then saves the destination and syncs once. No account is created on the device: the organization’s accounts arrive with that sync, and people sign in through Single Sign-On or, for the one person the sender named under Who is this device for?, by setting their own password once. That claim is checked against the roster the sync brought: both accounts active organization accounts, the sender still allowed to name that person, and the code unexpired. A Supervisor may name anyone, an Integrations Admin only accounts below the admin tier, and under the admins-only switch of section 5 an admin is pointed to Single Sign-On instead.
Backups. A plain backup is a signed JSON file without password hashes or credentials; accounts restored from it must have passwords reset. A passphrase-protected backup made by a Supervisor is the disaster-recovery image: it additionally carries every account’s password hash and every integration credential, only inside the AES-256-GCM envelope of section 3, and restores onto a replacement device with roles, sign-ins and integrations intact. A backup whose signature fails or is missing can only be imported after an explicit acknowledgment, and every account it brings in is downgraded to Inspector until an administrator re-assigns them.
7. Record integrity and the audit trail
Signed transitions. Each submit, review, approve, request-changes and reopen produces a signed envelope stored beside the record: the step, the account, the device key, the time, a commitment to the drawn signature image, SHA-256 digests of the record’s content (its fields, items, media rows and comments), and the signature of the previous step, so a dropped or replaced step is detectable. The private key is minted on the device at sign-in, sealed under the account password (a Single Sign-On account’s under a per-device secret, section 5), and never leaves the device; a password change retires it, and the roster of public keys keeps every earlier one so older signatures still verify.
Verification. Every device, and every exported report on its certification page, verifies each step and shows one of four results: Verified; Changed since signed, when a still-open record has moved on since an earlier step, which the next sign-off covers; Signed, key unknown, when the integrity check passes but the signer’s public key has not reached this device; and Failed. An approved record is locked, and any change to it after approval reads Failed rather than Changed. A step with no envelope reads Failed. The report also prints the record fingerprint so a printed copy can be matched to the signed record.
Audit trail. Every create, edit, delete and status change is written to an append-only log with the acting account, the time, and the previous and new values of changed fields. There is no path in the app that deletes an audit row. Text drafted by the AI Assistant is recorded, when it is saved, as an AI-assisted event naming the fields and where each was drafted (Apple Intelligence on the device, or the AI key), and an export that carried an AI-written summary or insights records that too. Events about inspections, items, media and comments travel with Data Sync so every device carries the whole team’s history; events about accounts, templates and backups stay on the device that recorded them.
Evidence. Photos and recordings are stored by content hash, GPS-tagged when permitted, and checked against the site geofence, with off-site captures flagged on the report cover. A report exported before approval carries a status watermark on every page. Location data can be stripped at export with one toggle when a report leaves the organization. To be exact about what the record establishes: a capture made in the app carries the account, the device and the moment; anything that reaches the record another way is tamper-evident from receipt, which is not the same as proof of when or where it was taken. GPS tags and the geofence are confidence signals and are labeled that way.
8. Input handling and hardening
- Every value crossing a trust boundary — typed in the app, arriving through Data Sync, or read from a backup — is validated and length-bounded before it touches the database. A malformed sync entry is quarantined on its own; the rest of the batch applies.
- AI output, from the device or a key, is treated as untrusted input: shown for review, then validated and bounded like anything typed.
- Reports are rendered on the device from escaped content into PDF; no remote resource is loaded into a report unless you configured a map provider.
- No embedded web views carry app content; Single Sign-On uses the operating system’s authentication session.
- No dynamic code loading, no remote configuration, no third-party SDKs of any kind: no analytics, advertising, crash reporting or attribution.
9. Supply chain and release engineering
- Dependencies. The production dependency tree is license-checked and audited for advisories in continuous integration; any advisory against a production dependency fails the build, and critical advisories against development tooling do too. The full component inventory with licenses ships in the app under Settings → Legal → Open Source Licenses, and a software bill of materials listing every shipped component with its version, license and package URL is available on request.
- Verification before release. Every change runs static analysis, type checking, unit tests covering the cryptography, signing, sync, licensing and sanitization paths, and an end-to-end suite that includes signing in through a real OpenID Connect identity provider.
- Export classification. The app uses standard, published algorithms over HTTPS and relies on Apple’s standard-algorithm exemption for App Store export compliance. Ask us for the paperwork your procurement process needs.
- Vulnerability reporting. Write to support@inspectionheroapp.com. Fixes ship as App Store updates.
10. Control mapping
Because no data reaches us, most controls are satisfied by what you already run on your devices, your storage and your identity provider. This table says which is which.
| Control area | Inspection Hero provides | Your organization provides |
|---|---|---|
| Access control (NIST SP 800-171 3.1, CJIS 5.5) | Six roles enforced in storage, reviewer/approver separation, locked approvals, idle lock and hourly re-authentication | Device passcode policy, MDM, who holds which role |
| Identification and authentication (3.5, CJIS 5.6) | Unique accounts, PBKDF2 password hashing, lockout, biometric unlock with password-gated signing, Single Sign-On with token verification on device | Multi-factor authentication and password policy at your identity provider |
| Audit and accountability (3.3, CJIS 5.4) | Append-only audit trail, signed workflow steps, record fingerprint on every report | Accurate device time via MDM, retention of synced history in your storage |
| System and communications protection (3.13, CJIS 5.10) | HTTPS-only connections, no vendor cloud, no telemetry, encrypted backups, sealed keys; FIPS status per section 4 | Encryption at rest and access policy on your storage, network boundary, trusted CA roots |
| Media protection (3.8) | Content-hashed evidence, location stripping at export, status watermark on unapproved reports | Handling of exported reports and backups |
| Configuration management (3.4) | Versioned templates, no remote configuration, updates only through the App Store | Update timing through MDM |
| Cloud service authorization (FedRAMP, StateRAMP, TX-RAMP) | Not a cloud service offering; nothing to authorize | Authorization of the storage service you connect, if any |
| Electronic records and signatures (21 CFR Part 11) | Each signature binds a named account, a time and the signed content; verification results on the record; approved records locked | Validation of your installed version, procedural controls |
| Third-party risk (DORA, FFIEC, subprocessor registers) | No provider in the data path, no subprocessors | Registers for the services you connect |
11. Short answers for the questionnaire
- Do you hold SOC 2, ISO 27001, FedRAMP, or CJIS certification? No, and there is no service of ours to assess: we never receive, process or store your records. The accredited environment you already run stays the boundary.
- Where is our data hosted? On your devices and in the storage you configure. Nowhere else.
- Do you have subprocessors? None. The services in section 1 are ones you choose and contract with directly.
- Do you need a data-processing agreement or a business-associate agreement? No, because no personal data or protected health information reaches us. We will sign a statement to that effect if your process requires one.
- Can you access our data for support? No. Support works from screenshots and descriptions you choose to share.
- What happens if our license lapses? Nothing is locked or deleted; paid features pause. Activation and expiry are verified on the device against the key’s signature and dates.
- Does the app use AI on our records? Only if a Supervisor turns the AI Assistant on, and the Supervisor chooses where it runs. With Apple Intelligence on supported devices it drafts on the device and sends nothing; with your AI key it sends each request from the device to the provider you configure, or to a model you host, never to us. Every AI-drafted field is reviewed before it’s saved and noted in the audit trail, with where it ran.
- How do you handle a breach? We hold no customer data to breach. A vulnerability in the app is fixed and shipped as an App Store update; report one to support@inspectionheroapp.com.
Questions this page does not answer: support@inspectionheroapp.com. We will walk through the architecture with your assessor and complete your questionnaire.