Service Incident Policy

01Purpose and scope

This policy explains how Ident.ink handles material availability, integrity and security incidents. It applies to the platform services we operate. It does not turn public status information into a guaranteed service level or replace a separately signed service-level agreement.

02Incident classification

• Platform-caused: a defect, deployment, configuration or operational action within Ident.ink’s reasonable control materially degrades service.
• Provider or dependency: a payment, email, DNS, network, connected platform or other independent supplier fails or restricts service.
• External or non-human event: weather, fire, flood, power-grid failure, natural disaster, widespread internet routing fault or other event not caused by a person acting for either party.
• Hostile or user-caused: attack, abuse, compromised customer credential, unlawful workload, misconfiguration or action by a customer or third party.

03Evidence and independent verification

Classification is based on monitoring, immutable or access-controlled logs, provider notices, network evidence, deployment records and other reliable data. A claimed external or non-human cause is not accepted merely because it is asserted; where material to responsibility, we seek corroboration from an independent provider, public authority, monitoring source or other technically credible evidence.

A mixed-cause incident is allocated according to the contribution of each cause. Evidence can change the preliminary classification.

04Response priorities

We first protect people, contain security risk and prevent data loss; then restore the safest core path; then recover dependent features and reconcile delayed work. Risky workloads may remain isolated after general recovery. Temporary degraded operation may be used when it is safer than full restoration.

05Status communication

Material incidents are posted to status.ident.ink when confirmed and operationally safe to disclose. Updates describe affected services, observed impact and current stage without publishing details that would enable attack or compromise an investigation. Estimates are best current assessments, not guarantees.

A resolved notice means normal monitoring shows service restored; follow-up work or a retrospective may continue. Historical status entries may be corrected when evidence changes.

06Backups and recovery

Ident.ink uses layered process supervision, health checks, database backups and recovery procedures appropriate to the service. These controls reduce risk but cannot guarantee zero loss or immediate restoration. Customers must retain independent copies of critical content, keys and financial records.

07Events outside reasonable control

Neither party is responsible for delay or failure caused by an event outside its reasonable control to the extent it could not reasonably be avoided or overcome, including independently evidenced non-human events, widespread infrastructure failure, government action, conflict, epidemic or major hostile attack. The affected party must take reasonable mitigation steps and resume performance when practicable.

This clause does not excuse payment already due, weakens no mandatory consumer right, and does not protect a party to the extent its inadequate preparation or own conduct caused the loss.

08Service credits

Credits are available only where an applicable plan or signed service-level agreement expressly promises them. Unless that agreement says otherwise, credits are calculated against the affected service fee, are not cash, cannot exceed that fee, and are the contractual availability remedy for a business customer without limiting liability that cannot lawfully be excluded.

Free, trial, promotional and partner access has no service-credit entitlement. Fraudulent, duplicate or incident-causing claims are rejected.

09Incident claim process

Submit the affected account, service, timestamps, observed error, region or network, and relevant evidence through Support. Never include passwords, complete card details or private keys. Claims are compared with monitoring and provider records. A status-page entry is useful evidence but does not by itself decide legal cause or entitlement.

10Post-incident improvement

For significant incidents we review detection, containment, recovery and prevention. Actions may include tests, fail-safes, dependency changes, capacity work and documentation. Security-sensitive detail may remain confidential. Material platform changes are summarised through transparency records where appropriate.