1. Security governance
Security responsibilities are assigned, access is limited by role, material administrative actions are audited, and changes are reviewed and tested before production deployment. Risk, provider, incident, privacy, backup, and recovery procedures are maintained as operational records.
2. Identity and access
- Customer and administrator authentication are separated, with restricted administrator roles.
- Authenticator-app multi-factor authentication is available for customer accounts.
- Administrative access follows least-privilege roles and is logged.
- Sensitive support access is authorized, scoped, time-limited where practical, and auditable.
- Session, password, and verification controls include expiration, rate limits, and abuse protections.
3. Data protection
Network traffic uses HTTPS/TLS. Sensitive stored request credentials are encrypted and are treated as write-only in customer and routine support interfaces. Cloud storage, databases, queues, and archives use encryption controls appropriate to their role. Secrets are kept out of public frontend code and are managed separately from source content.
Retention schedules minimize raw check and alert data while preserving required incident, consent, security, and financial records. Legal holds can suspend routine deletion for defined records when necessary.
4. Application and platform safeguards
- Tenant authorization is enforced by the API rather than trusted to the browser.
- Inputs, URLs, redirects, status-page slugs, uploads, and outbound monitoring targets are validated.
- Private, reserved, local, and unsafe network destinations are blocked or restricted to reduce server-side request forgery risk.
- Rate limits, quotas, bot challenges, idempotency controls, and queue back-pressure help limit abuse and cost amplification.
- Security headers and content policies reduce browser attack surface on customer-facing pages.
- Dependencies and supported runtimes are reviewed and updated as part of maintenance.
5. Monitoring-specific safeguards
Checks run through controlled workers with bounded timeouts, redirects, response sizes, retries, and diagnostic behavior. Encrypted headers and Basic Authentication values are excluded from public pages, ordinary logs, support summaries, and exported records. Public status-page branding and custom-domain features require ownership verification where appropriate.
No monitoring provider can prevent a target from logging the request or guarantee that every target will accept automated checks. Customers should use dedicated, least-privilege credentials and allow only the access needed for the selected endpoint.
6. Availability, logging, and recovery
Operational alarms monitor important worker, API, queue, scheduler, and delivery failures. Multi-location confirmation is used for qualifying failures. Capacity protections, dead-letter handling, backups, point-in-time recovery where configured, deletion grace periods, and controlled restore procedures support resilience and recovery.
Security and administrative logs are access-restricted and retained according to their operational, legal, and forensic purpose.
7. Security incident response
StackResolve maintains processes to identify, contain, investigate, recover from, and document security and privacy incidents. Customers and regulators are notified when required by applicable law or contract. Our Data Processing Addendum describes processor notification and assistance commitments.
8. Service providers
Providers are selected according to their function, security measures, contractual commitments, and data role. Access is limited to what is needed for the service. Current providers and primary processing locations are listed on the Sub-processors page.
9. Customer security responsibilities
- Use a unique password, enable multi-factor authentication, and protect account devices and email access.
- Monitor only targets you are authorized to test.
- Use dedicated least-privilege credentials and rotate them after suspected exposure.
- Review verified alert destinations, public status pages, custom domains, API tokens, and integrations regularly.
- Do not place secrets or personal information in monitor names, URLs, public descriptions, or support messages.
- Report suspected compromise promptly and preserve relevant evidence.
10. Assurance and limitations
This overview describes current high-level practices and is not a certification, audit report, warranty, or service-level agreement. Controls may change as threats, providers, technology, and legal requirements evolve. StackResolve does not currently claim SOC 2, ISO 27001, PCI DSS service-provider, or other independent certification unless expressly provided in a current written report.
Security questionnaires and additional documentation may be requested at security@uptimebasics.com.