Infrastructure Security
The managed OpsPing cloud runs as a single Go service binary on one AWS EC2 instance in us-east-2 (Ohio), backed by a PostgreSQL database (single-table design) with automated daily backups. Email is delivered via AWS SES. We deliberately keep the infrastructure small — fewer moving parts, fewer places for things to go wrong. Private single-tenant deployments run the same application on infrastructure you or we manage.
Data Encryption
- In transit: All communication uses TLS 1.2+, terminated by Caddy in front of the application. HTTP requests are redirected to HTTPS.
- At rest: All data resides in PostgreSQL on the application host's instance storage, with automated daily database backups. Sensitive fields — channel values (on-call phone numbers and email addresses) and MFA secrets — are additionally encrypted at the application layer with AES-256-GCM.
- API keys: Stored as bcrypt hashes in the database. No plaintext API keys exist in our database. After initial creation display, keys cannot be retrieved — only rotated.
Network Security
- The only public-facing component is Caddy on the application host. It terminates TLS, redirects HTTP to HTTPS, sets security headers, and proxies to the service listening on localhost.
- The application talks to SES and S3 over TLS to AWS service endpoints, to the PostgreSQL database locally on the host, and to push/SMS/voice providers (Expo, Twilio) over HTTPS. No third party has a network path into the database.
- SSH access is key-only — password authentication is disabled. Application-level rate limiting guards authentication and alert-ingestion endpoints.
Access Control
- IAM: The EC2 instance runs under an IAM instance role scoped to SES sending and S3 attachment storage — least privilege, no standing console credentials on the host, no database credentials in IAM.
- API auth: API keys (OpsPingKey / GenieKey-compatible) for programmatic access, and signed JWTs for mobile/web sessions. Both are validated on every request.
- Infrastructure access: Server changes follow a documented deploy runbook. Per-customer (single-tenant) infrastructure is provisioned with OpenTofu (
tofu/aws-silo). - Employee access: Production host access is over SSH with individual keys. As described under Zero Standing Access below, this does not grant anyone the ability to read customer alert data.
Application Security
Authentication
- Passwords are hashed with bcrypt. TOTP-based MFA with backup codes is available, and admins can reset a user's enrolled factor.
- API keys are random tokens with per-key scoping (read, write, delete, config) and optional binding to a specific team. Keys are stored only as hashes.
- JWT access tokens expire after 15 minutes by default; refresh tokens last 30 days with rotation. Password resets, blocks, and role changes invalidate all outstanding tokens immediately.
- Account recovery requires verified email. Authentication and registration endpoints are rate-limited.
Input Validation & Output Encoding
- All API inputs are validated server-side by the Go backend's typed request schemas. Unknown fields are rejected (HTTP 400), not silently stored.
- Dynamic content rendered in the admin dashboard is escaped via React's default JSX escaping.
- API responses set
Content-Type: application/json— no content sniffing possible. - CSP headers configured on the admin dashboard and marketing site.
Dependency Management
- Dependencies are pinned: exact versions in
package-lock.json(clients and tooling) andgo.sum(backend). - Automated Dependabot alerts for known CVEs. Critical patches applied within 48 hours.
- Runtime: the API is a compiled Go static binary (go 1.27 per
go.mod); client build tooling runs on Node.js LTS.
Zero Standing Access
OpsPing staff hold no standing access to your data. The system is built so that we can't read your alerts unless you explicitly let us — and when you do, everything we do is recorded in your own audit log.
Tenant Isolation
- Every organization's data is scoped to a tenant id. Cross-tenant access is denied by default — there is no code path that lets staff read another customer's alerts, teams, or users.
- The same isolation machinery guards every request; staff accounts get no bypass.
Support Access by Invitation
- When you need hands-on help, you invite [email protected] into your organization through the normal invite flow, with the least role needed for the task.
- You can revoke access at any time by deleting the user or letting the invite lapse.
- Every action support takes while invited lands in your audit log, attributed to the support account — nothing happens off the record.
Break-Glass Accountability
- Manual database intervention is a documented, exceptional runbook — never routine support.
- A point-in-time backup is taken before any manual intervention.
- Wherever possible the work itself is done through the normal audited UI (via a temporary user inside your tenant) so your audit log records it; direct item edits are a last resort and are documented with exact before/after values.
- Every intervention ends with an incident record: what was done, why, by whom, and when.
Compliance & Certifications
SOC 2
OpsPing is not pursuing SOC 2 certification — no independent audit has been conducted and none is planned. Our practices are mapped to the SOC 2 Trust Services Criteria, in depth, on our SOC 2 page.
GDPR
OpsPing is GDPR compliant. All customer data is stored in AWS us-east-2 (Ohio, USA). We offer a Data Processing Agreement (DPA) for customers who need one. See our Privacy Policy for details on data handling, retention, and deletion.
Data Retention
- Alerts: retained for 90 days by default (configurable per team).
- Audit logs: retained for 1 year.
- API key usage logs: retained for 30 days.
- Account data: deleted within 30 days of account closure.
Vulnerability Disclosure
If you discover a security vulnerability in OpsPing, please report it to [email protected]. We investigate all reports and respond within 48 hours. We don't run a public bug bounty yet, but we credit researchers in our changelog (with permission).
Do not attempt to access, modify, or delete other users' data when testing. Use your own account and test alerts only.
Questions?
Contact [email protected] for security questions, DPA requests, or penetration testing coordination. We're happy to provide additional documentation for your security review.
Enterprise Security Questionnaire
Evaluating OpsPing for your organization? This section answers the questions we most commonly receive in vendor security assessments. Because OpsPing is in beta, several answers describe work in progress — we disclose limitations plainly so your team can make an informed risk decision.
Product Overview
OpsPing is a SaaS on-call paging and alerting product for DevOps and operations teams, consisting of a React Native (Expo) mobile application and an AWS-hosted backend. Alerts are delivered via push notifications (relayed through Expo's push service), email (Amazon SES), and optional SMS/voice (Twilio).
Data Handling
| Question | Answer |
|---|---|
| What data do you process? | Account information (name, email, credentials), channel PII (on-call phone numbers and email addresses), mobile push tokens, alert logs and operational data (schedules, escalations, acknowledgements), and IP addresses / technical logs. |
| Where is data stored? | Amazon Web Services (PostgreSQL on EC2, single-table design), United States. |
| How long is data retained? | Alert logs and operational data: 90 days, then automatically and permanently purged. Account and channel data: retained while the account is active. Deletion requests honored within 30 days. |
| Is data encrypted in transit? | Yes — TLS 1.2 or higher on all connections. |
| Is data encrypted at rest? | Yes — sensitive fields (channel contact details, MFA secrets) are encrypted at the application layer with AES-256-GCM, and the database is protected by automated daily backups. |
| Is data used for advertising or sold? | No. We do not sell personal information or use it for advertising. |
Channel PII encryption: on-call phone numbers and email addresses are encrypted at the application layer (AES-256-GCM) in addition to infrastructure-level protections. MFA secrets receive the same treatment.
Subprocessors
We share personal data only with the subprocessors needed to operate the Service — AWS (hosting, database, and email via Amazon SES), Expo (push notification relay), and Twilio (optional SMS/voice). See the full subprocessor list for purposes, data processed, locations, and SOC 2 status. Customers are notified at least 30 days in advance of subprocessor changes, with a 14-day objection window (see our DPA).
Security Measures
- Access control: AWS IAM with least-privilege access; production access limited to authorized personnel.
- Encryption in transit: TLS 1.2+.
- Encryption at rest: PostgreSQL datastore on the application host with automated daily backups.
- Application-layer encryption: AES-256-GCM applied to channel values and MFA secrets.
- Penetration testing: No third-party penetration test results are available yet. Penetration testing is planned post-beta.
- Vulnerability management: Dependency monitoring and patching on a best-effort basis during beta.
Compliance Status
| Question | Answer |
|---|---|
| Do you have SOC 2? | No, and certification is not planned. Our practices are mapped criterion-by-criterion to the Trust Services Criteria on the SOC 2 page. |
| Is a DPA available? | Yes — a GDPR-style Data Processing Agreement is available, designating OpsPing as processor and the customer as controller. |
| Do you support EU data transfers? | Yes — via EU Commission Standard Contractual Clauses (2021 SCCs), Module Two (controller-to-processor), incorporated into the DPA. |
| GDPR data subject requests? | Access and deletion requests are honored within 30 days of a verified request. |
Incident Response
- Breach notification: Customers are notified of any personal data breach affecting their data within 72 hours of OpsPing becoming aware of it.
- Status page: OpsPing's own service status is published at ops-ping.com/status, and per-customer status pages live at status.ops-ping.com. Service disruptions during beta are also communicated directly to affected customers by email.
Business Continuity & Disaster Recovery
| Question | Answer |
|---|---|
| Infrastructure resilience? | Single-EC2 production silo today (us-east-2) — nightly pg_dump backups + infrastructure-as-code rebuild; a multi-AZ / multi-instance split is a post-beta hardening item. |
| RPO | Minimal — automated nightly database backups (PostgreSQL on the application host); no formal RPO target is committed during beta. |
| Formal DR plan? | Not yet. A documented disaster recovery plan is planned post-beta. During beta, recovery relies on nightly pg_dump backups and infrastructure-as-code rebuild capability; the production silo is a single EC2 instance (not multi-AZ). |
Security questions not covered here: [email protected]. This questionnaire reflects the current state of the beta product and will be updated as controls mature.