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 environment
• 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, incident response) are part of the engineering function.

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 security review, runs at least quarterly and after any material architecture change. Review reports are available to customers under NDA.
• Vulnerability scanning: dependencies are checked for known vulnerabilities on every build and in a quarterly review, and automated secrets scanning and static analysis run on every change. Critical findings are prioritised for immediate patching.
• 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 infrastructure-as-code; resources outside this inventory are not used to process customer data.

5. Access control

Customer-side

• Authentication, email address and password with a one-time code to the verified email, through the Hovermarks tenant on 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)

• Access to production is limited to named Hovermarks staff and requires phishing-resistant multi-factor authentication.
• Elevated access is granted only when needed, and removed afterwards where the Azure service supports it.
• Staff actions in the Hovermarks admin console are recorded in the audit log.

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 list of staff with production access
• 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	All service-to-service traffic is encrypted with TLS 1.2+. Access to the database, storage, key vault and AI services is controlled by Microsoft Entra identities and role assignments, with no credentials in the code.
Key management	All application secrets in Azure Key Vault. Keys are rotated annually for long-lived items, immediately on suspected exposure.
Signed artefacts	The audit log is HMAC-chained per tenant, and the chain is checked automatically.

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 with the organisation, the user and the request path.
• 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 notify the responsible engineer automatically.

Vulnerability management

• Dependencies are checked for known vulnerabilities on every build and in a quarterly review, and automated secrets scanning and static analysis run on every change. Critical findings are prioritised for immediate patching.
• Container base images follow Microsoft's release cadence. We rebuild and redeploy within 14 days of a critical vulnerability in the runtime.
• Internal security reviews run at least quarterly. Remediations from every review are tracked to closure.

Change management

All changes to production code or infrastructure flow through:

1. Source control with version history
2. Review against a documented checklist
3. Automated build + test + security scan in CI
4. Automated deploy to production on merge to main; the API deploy runs the full API test suite first and stops if any test fails
5. A post-deploy health check and log-stream review; the previous revision is kept, and traffic can be shifted back to it in under a minute

9. Network security

• Public traffic reaches the service through managed edge networks that terminate TLS and provide DDoS protection.
• The application reaches its database, storage and Key Vault with its Microsoft-managed identity. No service credentials are embedded in code.
• Sign-in is rate-limited to block credential-stuffing attempts.

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: dependencies are checked for known vulnerabilities on every build and in a quarterly review; critical findings are prioritised for immediate patching. Secrets scanning runs on every change.
• Static analysis: strict type checking on every build, and automated static analysis on every change.
• Periodic security review: an internal 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 responsible engineer.
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 security@hovermarks.com 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.
• 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.

Other frameworks:

• 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, 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 security@hovermarks.com.