Information Security Policy

This Information Security Policy ("ISP") describes the controls Hovermarks operates to protect the confidentiality, integrity, and availability of customer data. It applies to every component of the Hovermarks Inspection platform — the application, infrastructure, third-party sub-processors, and the people who operate the service.

The policy is reviewed at least annually and after any material change to how the service is built or operated. The version is set by the "Last updated" date above.

1. Purpose and scope

The purpose of this ISP is to give customers, partners, and regulators a single document explaining how we secure the platform. The scope covers:

• The Hovermarks Inspection web application and mobile experience
• The Azure-hosted production and development environments
• All data customers entrust to us under the Data Processing Agreement
• All personnel with operational access to production

Customer-side controls (passwords, MFA enrolment, role assignment within a tenant) sit with the customer's tenant administrator and are out of scope of this ISP — they are covered by the Hovermarks user documentation and the Terms of Service.

2. Governance

Information security accountability rests with the Hovermarks Security Lead, who reports to the company's leadership. Responsibilities include:

• Maintaining this policy and the published Privacy Notice + DPA
• Owning the risk register and the annual risk assessment
• Approving any change to security-impacting configuration
• Coordinating incident response and customer communications
• Reviewing this policy at least annually

Day-to-day operational security tasks (deployments, alerts, on-call) are integrated into the engineering function. There is no separate operations or compliance team at the current company size — this is intentional and documented so customers can size their assurance needs appropriately.

3. Risk management

We maintain a documented risk register covering threats to confidentiality, integrity, and availability of customer data. The register is reviewed at least annually, and after any material change to the platform's architecture, sub-processor list, or threat environment. Each entry records the threat, current control, residual risk, and the next planned action.

Security review cadence:

• Internal multi-agent pentest — runs at least quarterly and after any material architecture change. Internal review reports are available to customers under NDA. Commissioning an independent external penetration test is on the post-GA roadmap.
• Vulnerability scanning — continuous dependency vulnerability scanning in CI (dotnet list package --vulnerable and the equivalent for the dashboard's npm tree). Critical findings block releases.
• CVE sweep — quarterly review of the live dependency graph against published CVE feeds.

4. Asset management and data classification

We classify customer data into four tiers:

Tier	Examples	Handling
Confidential	Inspection records, customer contact data, billing data	Encrypted at rest and in transit; access restricted to MSI / authenticated users with role-scoped query filters; logged on every read or write
Internal	Tenant metadata, configuration, audit log entries	Same as Confidential
Restricted	Cryptographic keys, signing secrets	Held only in Azure Key Vault; never logged, never embedded in source
Public	Marketing site content, /security trust page	Standard web hygiene

We maintain an inventory of every Azure resource backing the service in our infrastructure-as-code (Bicep) repository; resources outside this inventory are not used to process customer data.

5. Access control

Customer-side

• Authentication — Microsoft sign-in by default; password
  • Email-OTP via Microsoft Entra External ID; bring-your-own Microsoft Entra SSO on Professional plans and above.
• Multi-factor authentication (MFA) — required on every sign-in via a Conditional Access policy targeting the Hovermarks Enterprise Application on the External ID identity tenant.
• Role-based access control — four roles inside a tenant (TenantAdmin, SiteManager, Inspector, Contractor) with documented capability differences. Database row-level filters enforce that users can only see their tenant's data.
• Session management — short-lived signed JWTs verified on every API call; sessions revoke on sign-out and on password change.

Operator-side (Hovermarks personnel)

• Production access uses Microsoft Entra OIDC sign-in with hardware-token MFA. Privilege is granted via membership in a named PlatformSuperAdmins allow-list, not an implicit role.
• Just-in-time access for sensitive operations is preferred where the underlying Azure resource supports it.
• All operator actions on customer data are recorded in the tamper-evident audit log alongside the customer-side audit trail.

Joiners / movers / leavers

For each role change of a Hovermarks staff member with operational access:

• Access is provisioned only after a written role assignment
• Reviewed quarterly against the live PlatformSuperAdmins list
• Revoked within 24 hours of role change or leaving the company

6. Cryptography

Layer	Standard
At rest	AES-256, Azure-managed encryption keys for Postgres, Blob, Key Vault. Customer-managed keys (CMK) available on the Enterprise tier on request.
In transit	TLS 1.2 or higher enforced on every public endpoint. TLS 1.0 and 1.1 are disabled.
Inside the data centre	Service-to-service traffic crosses an Azure VNet; never the public internet.
Key management	All application secrets in Azure Key Vault. Keys are rotated annually for long-lived items, immediately on suspected exposure.
Signed artefacts	Inspection certificate PDFs carry a SHA-256 hash chained across tenant submissions. The chain is verified nightly; breaks raise a critical alert.

7. Physical and environmental security

Hovermarks runs on Microsoft Azure UK South, with geo-redundant storage replication to Azure UK West for disaster recovery. We do not operate any physical infrastructure of our own; the physical and environmental controls inherit from Microsoft Azure, which holds ISO/IEC 27001, SOC 2 Type II, and ISO 22301 certifications for the relevant data-centre regions.

8. Operations security

Logging and monitoring

• Every API request is logged to Application Insights with the invoking tenant identifier, user identifier, and request path. Log volume retention follows the Azure default (90 days hot, archived to longer storage if a tenant requests it).
• A separate, append-only audit log records every meaningful change in a tenant (sign-in, role change, asset edit, inspection submission, work-order status change, settings change). Entries are chained by SHA-256 hash so a single byte change to an historical entry breaks the chain.
• Critical operational alerts page the on-call contact via an Azure Monitor Action Group (email).

Vulnerability management

• Continuous dependency scanning in CI for both .NET and npm dependency graphs. Critical findings block releases.
• Operating-system base image refreshes follow Microsoft's release cadence for mcr.microsoft.com/dotnet/aspnet:8.0. We re-build and re-deploy within 14 days of a critical CVE in the runtime.
• Internal security reviews (multi-agent static pentest + live CVE sweep) run at minimum on a quarterly cadence; commissioning an external penetration test is on the post-GA roadmap. Remediations from every review are tracked to closure in commit history under the sec(...) prefix.

Change management

All changes to production code or infrastructure flow through:

1. Source control with version history
2. Peer review (where multiple operators are available) or structured self-review against a documented checklist
3. Automated build + test + security scan in CI
4. A staged deploy through development, then production
5. A post-deploy verification step including liveness probe, exception-rate check, and log-stream review

9. Network security

• The application sits behind Cloudflare's edge for TLS termination, WAF, and DDoS protection.
• Customer-facing identity flows pass through Azure Front Door for TLS to the CIAM tenant.
• The application talks to its data plane (Postgres, Blob, Key Vault) exclusively via Microsoft-managed identity (MSI). No long-lived service credentials are embedded in code or deployment artefacts.
• A rate-limit rule on the OAuth authorisation endpoint blocks credential-stuffing patterns at the edge.

10. Secure development

• Source control: all code lives in Git with full history.
• Code review: every change is reviewed before merge to the main branch, either by a second human reviewer or by a structured automated review pattern that exercises the same checks (input-validation completeness, authorisation gating, secret handling, dependency hygiene).
• Dependency scanning: every CI build runs the vulnerability scanner for the .NET solution and the dashboard's npm graph; Critical findings block release.
• Static analysis: TypeScript and C# strict-mode compilations are enforced; any new lint or compiler warning blocks merge.
• Periodic security review: a multi-agent static security audit is run quarterly against the full codebase. The most recent report is dated and tracked to closure.

11. Supplier security

We use a small, named list of sub-processors. The complete list with the data each handles and the region it operates in is published at /legal/subprocessors. All sub-processors are selected on the basis of:

• Holding an equivalent or stronger security posture than this policy (verified by published certifications — typically ISO/IEC 27001 and SOC 2 Type II)
• Operating under contractual data-protection terms compatible with the Hovermarks Data Processing Agreement
• Hosting in the United Kingdom or European Economic Area where practical; transfers outside the UK / EEA are governed by Standard Contractual Clauses

We notify customers in advance of any addition to the sub-processor list and provide a window to object.

12. Incident management

We follow a documented incident response process:

1. Detect — automated alerts from Azure Monitor and the in-application audit log surface anomalies to the on-call contact.
2. Triage — assess scope, affected data, and severity within 1 hour of detection.
3. Contain — implement immediate containment (key rotation, access revocation, traffic block) before root-cause investigation.
4. Investigate — gather evidence, identify root cause, and confirm the boundary of affected data.
5. Notify — for any incident affecting customer data, notify the data controller (the customer's TenantAdmin) within 72 hours of becoming aware, per the Data Processing Agreement. For less severe incidents we notify at the next scheduled customer-comms touchpoint with a description of cause and remediation.
6. Remediate — ship fixes; verify in production; track regression in the next review cycle.
7. Post-mortem — written report of root cause, customer impact, remediation, and process changes. Provided to affected customers on request.

A coordinated-disclosure mailbox at [email protected] is documented on the /security page and via the RFC 9116 file at /.well-known/security.txt.

13. Business continuity and disaster recovery

• Backup posture — Postgres point-in-time restore (PITR) with a 7-day window; geo-redundant backup to UK West for both production and development.
• Recovery objectives — RTO approximately 4 hours; RPO approximately 1 hour. These are operational targets, not contractual commitments, and may be tightened by customer agreement.
• Drill cadence — PITR is exercised at least quarterly with the drill report retained for audit.
• DR runbook — versioned in source control alongside the infrastructure code; reviewed at the same cadence as this policy.

14. Compliance

Hovermarks operates under UK GDPR and (where applicable) the EU GDPR as a data processor; the customer remains the data controller. Sub-processor management, Standard Contractual Clauses for cross-border transfers, and breach notification SLAs are all governed by the Data Processing Agreement at /legal/dpa.

Compliance certifications are tracked on a roadmap that aligns to customer demand:

• SOC 2 Type II — under consideration; pursued when at least two enterprise prospects require it as a procurement gate.
• ISO/IEC 27001 — not on the immediate roadmap; SOC 2 covers most overlapping requirements at lower cost.
• PCI DSS — Hovermarks does not store, process, or transmit cardholder data. All payment surfaces are delegated to Stripe; PCI scope reduces to the SAQ A self-assessment.
• HIPAA / FedRAMP — not applicable to current customer base.

15. Human resources security

Hovermarks personnel with operational access:

• Pass a background check at engagement (criminal record and right-to-work checks where local law permits)
• Sign a confidentiality agreement covering customer data
• Complete security-awareness training at engagement, then annually
• Have their access reviewed quarterly

When personnel leave or change role, access is revoked within 24 hours.

16. Acceptable use

Hovermarks personnel who have access to customer data must:

• Use it only for the operational purpose required by their role
• Never copy customer data to personal devices or storage
• Never share customer data with third parties unless contractually required and authorised by the Security Lead
• Report any suspected security incident immediately to the Security Lead via the documented internal channel

Personal devices used for Hovermarks operations are subject to disk encryption, an enforced screen lock, and current operating-system patching. We do not currently operate a full mobile device management solution; the equivalent expectation is met by policy and verified during the quarterly access review.

17. Document control

Field	Value
Owner	Hovermarks Security Lead
Last reviewed	See "Last updated" date in the page header
Review cadence	At least annually; additionally on any material change to the platform
Approval	Approved by Hovermarks leadership at each annual review
Distribution	Published publicly at /legal/information-security-policy

Questions about this policy or requests for a signed PDF copy can be sent to [email protected].