A real sample security pack
Public-source specimen: Healthchecks.io. An independent demonstration generated from public Healthchecks.io documentation. Healthchecks.io did not provide or endorse this sample.
This is the exact artifact produced by the production generation engine, validator gate, and customer rendering. The public-source prompt mode uses third-person language and an independent provenance line instead of claiming the specimen supplied an attestation. Nothing here is staged or hand-edited.
Method: Public-source review of the hosted service and its open-source repository; each cited page was fetched successfully before the production generation pipeline ran. No private access or vendor questionnaire responses were used.
Scope: Healthchecks.io hosted-service controls documented on the cited pages as of 2026-08-28. Unpublished controls are labelled “not evidenced,” not treated as absent.
Sources reviewed on 2026-08-28:
Healthchecks.io — Security & Trust
Based on public information about Healthchecks.io reviewed on 2026-08-28. Independent Trustpack demonstration; not provided or endorsed by Healthchecks.io, and not an audit or certification.
Overview
Healthchecks.io is an open-source hosted service that monitors cron jobs and scheduled tasks. The service is operated by a one-person team. Its security posture reflects that scale: controls are specific and documented where they exist, and this page identifies areas where public evidence was not found.
Infrastructure & Hosting
Healthchecks.io runs on Hetzner bare-metal servers located in Germany. Customer data does not leave Germany at rest except for encrypted off-site backups (see Data Protection). Hetzner states ISO 27001 certification for its own infrastructure; no equivalent certification was evidenced for Healthchecks.io itself. Inter-server traffic is protected with WireGuard. Client-to-server traffic uses HTTPS.
A PostgreSQL hot standby is documented, and database failover is performed manually. No separate disaster-recovery runbook was evidenced in the reviewed public sources. Service availability is tracked at the public status page: https://status.healthchecks.io/
Data Protection
Data categories stored: account email address and optional password, billing and contact information, notification-service credentials, support messages, browser and server logs, IP address, device and referral data, time zone, and customer-supplied check data.
Encryption in transit: HTTPS for client-to-server traffic; WireGuard between servers.
Encryption at rest: Primary database data is not encrypted at rest. Off-site database backups are GPG-encrypted; subprocessors do not hold the encryption key. Encrypted backups are stored on Amazon Web Services.
Backups: Daily GPG-encrypted PostgreSQL backups are stored off-site. Deleted information may remain recoverable in those backups for up to 2 months.
Data deletion and retention: Customers can close their account at any time. Inactive accounts are closed after 1 year, preceded by a 30-day notice. Deleted information may remain in database backups for up to 2 months.
Data export: Customers may request access and portability under the privacy policy. Project and check data are also accessible through the documented API.
GDPR: The privacy policy supports access, correction, deletion, processing restriction, objection, and portability requests. Affected customers are notified without undue delay following a breach; supervisory authority notification occurs within 72 hours where required. A published Data Breach Policy covers reporting, containment, investigation, customer notification, remediation review, and a public incident report.
Access & Authentication
Customers sign in with an email address and an optional password. The open-source codebase also documents WebAuthn two-factor authentication for customer accounts. The public FAQ identifies a one-person operations team with access to production systems. No more granular production-access policy was evidenced in the reviewed public sources.
Monitoring & Vulnerability Management
The privacy policy states that regular vulnerability monitoring is performed. The public repository security policy directs vulnerability reports to contact@healthchecks.io. The BSD-licensed source code and full change history are publicly available at https://github.com/healthchecks/healthchecks. Browser, device, server, IP-address, referral, access-time, and operating-system logs are documented in the privacy policy; a retention period for those logs was not evidenced.
Subprocessors
| Name | Purpose |
|---|---|
| Hetzner | Hosting and primary data storage |
| Amazon Web Services | Encrypted off-site database backups |
| Twilio | SMS and WhatsApp notification delivery |
| Braintree | Payment processing |
| Fastmail | Email hosting |
Current Posture & Public-Evidence Gaps
Documented in the cited public record:
- Hetzner bare-metal hosting in Germany with Hetzner's stated ISO 27001 certification
- HTTPS and WireGuard encryption in transit
- Daily GPG-encrypted off-site backups with 2-month recoverable retention window
- PostgreSQL hot standby with documented manual failover
- Customer WebAuthn two-factor authentication
- Published Data Breach Policy with 72-hour supervisory notification commitment
- GDPR data-subject request support
- Public source code at GitHub
Not evidenced in the reviewed public record:
- Healthchecks.io security certification (SOC 2, ISO 27001, or equivalent)
- Staff two-factor authentication enforcement
- Customer SSO
- Staff endpoint security controls
- Third-party penetration test
- Log retention period
- Cyber-liability insurance
Contact
Security questions, vulnerability disclosures, and data-subject requests should be directed to contact@healthchecks.io.
Security Questionnaire Answer Bank — Healthchecks.io
Based on public information about Healthchecks.io reviewed on 2026-08-28. Independent Trustpack demonstration; not provided or endorsed by Healthchecks.io, and not an audit or certification.
Q: Is customer data encrypted at rest?
A: Primary database data on Healthchecks.io production servers is not encrypted at rest. Off-site database backups are GPG-encrypted before transfer, and subprocessors do not hold the decryption key. The separation of encryption responsibility means backup content is protected from storage-layer exposure at the off-site location.
Q: Is customer data encrypted in transit?
A: Healthchecks.io uses HTTPS for all client-to-server traffic. Inter-server communication is protected using WireGuard. No unencrypted transport paths were evidenced for in-scope data flows in the reviewed public sources.
Q: How is access to production systems and customer data controlled?
A: The public FAQ identifies a one-person operations team, meaning production access is limited to a single individual by the nature of the team's size. No more granular formal access-control policy or least-privilege documentation was evidenced in the reviewed public sources. Customer data categories in scope include account credentials, billing and contact information, notification-service credentials, IP addresses, and customer-supplied check data.
Q: Is multi-factor authentication enforced for staff accessing critical systems?
A: Staff MFA enforcement on critical systems was not evidenced in the reviewed public sources. For customer accounts, Healthchecks.io documents WebAuthn two-factor authentication as an available option within the open-source codebase. Whether any equivalent control is applied to the operator's own administrative access is not addressed in reviewed public materials.
Q: How are backups handled, and is there a disaster-recovery plan?
A: PostgreSQL backups are taken daily, GPG-encrypted, and stored off-site; the privacy policy states that deleted information may remain recoverable in those backups for up to two months. A PostgreSQL hot standby is documented, and database failover is described as a manual process. No separate, formally documented disaster-recovery runbook was evidenced in the reviewed public sources beyond the hot-standby arrangement.
Q: What is your incident-response and breach-notification process?
A: Healthchecks.io publishes a Data Breach Policy that covers reporting, containment, investigation, customer notification, remediation review, and a public incident report. Affected customers are notified without undue delay following a confirmed breach. Where legally required, a supervisory authority is notified within 72 hours.
Q: Which subprocessors have access to customer data?
A: Five subprocessors are identified in the reviewed public sources: Hetzner (hosting and data storage, located in Germany), Amazon Web Services (encrypted off-site database backups), Twilio (SMS and WhatsApp notification delivery), Braintree (payment processing), and Fastmail (email hosting). GPG-encrypted backups sent to AWS are encrypted before transfer, and subprocessors do not hold the decryption key.
Q: How can customers request data deletion, and how long is data retained?
A: Customers can close their account at any time; inactive accounts are closed after one year following a 30-day notice period. Deleted information may remain recoverable in database backups for up to two months before it is fully purged. The privacy policy supports formal deletion requests as part of GDPR data-subject rights, alongside access, correction, restriction, objection, and portability requests.
Q: How are software vulnerabilities and dependency updates managed?
A: The public repository security policy at github.com/healthchecks/healthchecks directs vulnerability reports to contact@healthchecks.io for coordinated disclosure. The privacy policy states that regular vulnerability monitoring is performed. The full source code and commit history are publicly available under a BSD license, enabling independent review of dependency changes.
Q: Do you offer SSO (Single Sign-On) for customer accounts?
A: Customer SSO availability was not evidenced in the reviewed public sources. Customer authentication is handled via email address with an optional password, and the open-source codebase documents WebAuthn two-factor authentication as an available customer-facing option. No SAML or OIDC-based SSO integration was identified in reviewed materials.
Q: What security certifications does Healthchecks.io hold?
A: No security certification held directly by Healthchecks.io was evidenced in the reviewed public sources. Hetzner, the bare-metal hosting provider where customer data is stored in Germany, states ISO 27001 certification for its data center operations. Healthchecks.io itself makes no certification claim beyond what its hosting provider's published materials describe.
Q: Does the service maintain audit or access logs?
A: The privacy policy documents collection of browser logs, server logs, IP addresses, device data, referral data, access times, and operating-system information. These logs cover both client-side and server-side activity relevant to access tracking. A specific retention period for these logs was not evidenced in the reviewed public sources.
Access Control & Identity Policy — Healthchecks.io
Based on public information about Healthchecks.io reviewed on 2026-08-28. Independent Trustpack demonstration; not provided or endorsed by Healthchecks.io, and not an audit or certification.
Scope
This document describes access control and identity practices for Healthchecks.io, a hosted cron-job and scheduled-task monitoring service operated as a one-person team. It covers customer-facing authentication, production system access, and account lifecycle management as evidenced in publicly available sources.
Account Provisioning and Deprovisioning
Customers create accounts using an email address with an optional password. Account provisioning is self-service; no manual approval step is documented.
Deprovisioning follows two paths. A customer may close their account at any time, which initiates data deletion. Inactive accounts are closed automatically after one year of inactivity, preceded by a 30-day notice period. Following account closure, deleted information may remain recoverable in database backups for up to two months, consistent with the documented backup retention window.
Production Access
The public FAQ identifies a one-person operations team as the sole party with access to production systems and customer data. Because the team size is one, the operational surface area for unauthorized internal access is inherently narrow. No more granular production-access policy — such as a written access matrix, approval workflow, or access review schedule — was evidenced in the reviewed public sources.
Production infrastructure runs on Hetzner bare-metal servers located in Germany. Server-to-server communication is protected by WireGuard. Client-to-server traffic is protected by HTTPS.
Authentication Requirements
Customer authentication. Customers authenticate with an email address and an optional password. The open-source codebase and its documentation also describe WebAuthn two-factor authentication as an available option for customers who choose to enable it.
Staff authentication. Because operations are conducted by a single individual, no multi-person access policy is documented. Enforcement of two-factor authentication on staff accounts or critical internal systems was not evidenced in the reviewed public sources.
Customer SSO. Availability of SSO (such as SAML or OIDC) for customer accounts was not evidenced in the reviewed public sources.
Least Privilege
With a one-person operations team, formal role-based access control with distinct privilege tiers is not documented publicly. The practical effect is that a single operator holds full administrative access to production systems. No separate read-only, support-tier, or developer access roles were evidenced in the reviewed public sources.
The primary database does not use encryption at rest, meaning anyone with file-system access to the Hetzner servers could read database contents. Off-site backups stored on Amazon Web Services are GPG-encrypted, and subprocessors do not hold the decryption key, which limits exposure at the backup-storage layer.
Public-Evidence Gaps
The following controls were not evidenced in the reviewed public sources. No inference is drawn about whether these controls exist, are planned, or are absent.
- Formal written production-access policy or access matrix
- Two-factor authentication enforcement for staff accounts on critical systems
- Customer SSO (SAML, OIDC, or equivalent)
- Privileged access management tooling or session recording
- Periodic access review process
- Staff device security controls
- Encryption at rest for the primary database
- Retention period for server, browser, and access logs
- Cyber-liability insurance
Security questions and vulnerability disclosures may be directed to contact@healthchecks.io. The source code for the service is publicly available at https://github.com/healthchecks/healthchecks under a BSD license.
Incident Response & Breach Notification Policy
Based on public information about Healthchecks.io reviewed on 2026-08-28. Independent Trustpack demonstration; not provided or endorsed by Healthchecks.io, and not an audit or certification.
Overview
Healthchecks.io operates a hosted cron-job and scheduled-task monitoring service on Hetzner bare-metal servers located in Germany. The service is run by a one-person operations team. The company publishes a Data Breach Policy that defines a structured sequence: reporting, containment, investigation, customer notification, remediation review, and a public incident report.
Detection and Reporting
Incidents may be identified through any number of channels, including server and access logs, browser and IP-address logs, or external disclosure. The public repository security policy directs vulnerability reports to contact@healthchecks.io. The privacy policy states that regular vulnerability monitoring is conducted. When a potential incident is identified, the process moves immediately to assessment.
Assessment
The Data Breach Policy names investigation as a distinct phase. During assessment, the scope and nature of any exposure is determined — including which categories of customer data may be affected. Healthchecks.io stores account email addresses and optional passwords, billing and contact information, notification-service credentials, support messages, browser and server logs, IP addresses, device and referral data, time zones, and customer-supplied check data. The severity of an incident is therefore evaluated against this data inventory.
Containment
Containment is a named phase in the published Data Breach Policy. Specific technical containment procedures beyond this naming are not detailed in the reviewed public sources. Infrastructure relevant to containment includes HTTPS for client-to-server traffic, WireGuard between servers, and GPG-encrypted off-site PostgreSQL backups stored with Amazon Web Services, where subprocessors do not hold the encryption key.
Customer Notification
The breach-notification commitment is stated in the published policy as follows: affected customers are notified without undue delay. Where notification to a supervisory authority is required under applicable law, that notification is made within 72 hours. This timeline aligns with the requirements of GDPR, under which Healthchecks.io supports access, correction, deletion, processing restriction, objection, and portability requests from data subjects.
Post-Incident Review
The Data Breach Policy identifies remediation review and a public incident report as the final phases of the process. This means that, following an incident, Healthchecks.io commits to reviewing what occurred and publishing an account of it. The format or minimum content of that public incident report is not further specified in the reviewed public sources.
Infrastructure Supporting Recovery
Healthchecks.io runs a PostgreSQL hot standby, with database failover documented as a manual process. Daily GPG-encrypted PostgreSQL backups are stored off-site at Amazon Web Services. The privacy policy notes that deleted information may remain recoverable in database backups for up to two months. A public status page is maintained at https://status.healthchecks.io/.
Public-Evidence Gaps
The following recovery and response controls were not evidenced in the reviewed public sources and cannot be confirmed or denied on the basis of available public information:
- A documented disaster-recovery runbook separate from the hot-standby configuration
- Defined recovery-time or recovery-point objectives
- Staff two-factor authentication enforcement on systems used during incident response
- Endpoint security controls for the staff device used in operations
- Third-party penetration testing or independent security assessment
- Retention period for browser, server, IP-address, and access logs
- Cyber-liability insurance coverage
Security questions and disclosures may be directed to contact@healthchecks.io.
Data Protection & Retention Policy
Based on public information about Healthchecks.io reviewed on 2026-08-28. Independent Trustpack demonstration; not provided or endorsed by Healthchecks.io, and not an audit or certification.
Data Categories Handled
Healthchecks.io stores the following categories of customer data: account email address and optional password; billing and contact information; notification-service credentials; support messages; browser and server logs; IP address; device and referral data; time zone; and customer-supplied check data (ping URLs, schedules, and status payloads).
Encryption in Transit
All client-to-server traffic is protected with HTTPS. Communication between internal servers uses WireGuard.
Encryption at Rest
Primary database data on Healthchecks.io's Hetzner bare-metal servers is not encrypted at rest. Off-site database backups are GPG-encrypted before transfer, and subprocessors do not hold the GPG key.
Backups and Retention Windows
PostgreSQL backups are taken daily and stored off-site in encrypted form. Deleted account or check data may remain recoverable within those backup files for up to two months following deletion. A PostgreSQL hot standby is documented; database failover is manual.
Data Deletion and Export
Customers may close their account at any time to request deletion. Inactive accounts are closed after one year of inactivity following a 30-day notice period. Following deletion, residual data may persist in database backups for up to two months.
For export, customers may request access and portability under the privacy policy. Project and check data are also accessible programmatically through the documented API.
Subprocessors
The following third parties process or store customer data on behalf of Healthchecks.io:
| Subprocessor | Purpose | Data Location |
|---|---|---|
| Hetzner | Hosting and primary data storage | Germany |
| Amazon Web Services | Encrypted off-site database backups | — |
| Twilio | SMS and WhatsApp notification delivery | — |
| Braintree | Payment processing | — |
| Fastmail | Email hosting | — |
Hetzner states ISO 27001 certification for its infrastructure. No Healthchecks.io-level security certification was evidenced in reviewed public sources.
GDPR Data-Subject Requests
Healthchecks.io's published privacy policy supports the following data-subject rights for individuals in applicable jurisdictions:
- Access — right to obtain a copy of personal data held
- Correction — right to rectify inaccurate data
- Deletion — right to erasure, subject to the backup retention window described above
- Restriction of processing — right to limit how data is used
- Objection — right to object to certain processing activities
- Portability — right to receive data in a structured, transferable format
Requests can be directed to contact@healthchecks.io. In the event of a personal-data breach, affected customers are notified without undue delay, and a supervisory authority is notified within 72 hours where required. Customer data is stored in Germany.
Public-Evidence Gaps
The following items were not evidenced in the public sources reviewed and are therefore documented here as gaps rather than confirmed or denied controls:
- Encryption at rest for the primary production database
- Retention period for browser, server, IP-address, and access-time logs
- Specific data-center locations used by Amazon Web Services for backup storage
- Specific data-handling regions for Twilio, Braintree, and Fastmail
- Data Processing Agreement (DPA) availability for enterprise customers
- Formal data-classification or data-inventory documentation beyond the privacy policy