APOLLO Insurance · Trust Center
Apollo Insurance Trust Center
Trust center
APOLLO Insurance maintains a public trust center documenting SOC 2, ISO 27001, and PCI DSS compliance.
InsuranceCanadaInsurtechBrokerEmbedded InsuranceProperty and CasualtyTenant InsuranceQuotingDistributionCompliance
Trust center: https://apollocover.com/security
Certifications & Compliance
SOC 2ISO 27001PCI DSS
Source
Trust Center
generated: '2026-07-25'
method: searched
probe: true
source: https://apollocover.com/security
url: https://apollocover.com/security
title: Security at APOLLO
type: security-posture-page
note: >-
This is a published security posture page, not a trust portal. There is no trust.apollocover.com,
no document request flow, no audit report, no certificate and no subprocessor list. It is
detailed and specific — unusually so for a Canadian broker — but every named certification is
INHERITED from an infrastructure or payment vendor. APOLLO does not claim a SOC 2, ISO 27001 or
PCI DSS certification of its own.
certifications:
- SOC 2
- ISO 27001
- PCI DSS
certifications_detail:
- name: SOC 2 Type 2
held_by: AWS data centres, and Stripe
apollo_held: false
quote: >-
"The data centers used for storing your content and allowing it to be delivered to your users
are also certified for compliance with the SOC 2 Type 2 standard."
- name: ISO 27001
held_by: AWS
apollo_held: false
quote: >-
"Physical security to our servers and to your data is managed by AWS security certifications"
(linking to https://aws.amazon.com/compliance/iso-27001-faqs/)
- name: PCI DSS
held_by: Stripe
apollo_held: false
quote: >-
"APOLLO uses Stripe to process credit card payments, which means that no credit card
information or related payment information is stored on our servers. Stripe enforces
stringent PCI DSS (Payment Card Industry) compliance criteria..."
apollo_operated_controls:
encryption:
at_rest: AES-256 in AWS S3, DynamoDB and EBS; keys in AWS KMS
in_transit: HTTPS/TLS v1.2 minimum, including to the CDN
testing: annual third-party penetration tests of infrastructure, web applications and APIs
vulnerability_management: internal severity classification with an internal SLA for fixes, post-mortems where warranted
sdlc: >-
Bitbucket pull-request peer review, pair programming, automatic static code analysis and
dependency scanning (SonarCloud) in CI, separate QA AWS account with no production data,
security-by-design embedded in the product organisation
monitoring: AWS GuardDuty, DataDome (bot/fraud/DDoS), third-party 24/7 SOC, CloudTrail across all environments, OpsGenie escalation
network: AWS security groups, Web Application Firewall, AWS Shield
access: role- and permission-based access to customer data, all actions recorded and audited; MFA enforced across AWS and Bitbucket
resilience: multi-region replication, versioned S3 buckets, point-in-time recovery to 35 days
data_retention: documented Data Retention and Data Classification policies; application logs retained 365 days minimum
incident_response: >-
documented incident response plan covering notification and cooperation with customers, data
protection authorities and law enforcement; affected customers notified without undue delay
people: security and privacy training for employees and contractors, confidentiality clauses in standard contracts
vendor_management: risk assessment of every SaaS/tool; contractual privacy and security commitments required of third parties
end_user_controls: two-factor authentication via email; minimum 8-character password policy with complexity requirement
gaps:
vulnerability_disclosure: >-
No coordinated vulnerability disclosure channel. The page describes internal vulnerability
management but publishes no security contact address, no responsible-disclosure policy, no
safe-harbour statement and no bug bounty. There is no /.well-known/security.txt on any host.
A researcher who found a flaw would have to use the general contact form.
audit_reports: none offered, and no request mechanism
subprocessors: no subprocessor list published
own_certifications: none — every named certification belongs to AWS or Stripe
status_page: none
privacy_regime: >-
PIPEDA and provincial privacy law apply, and a public privacy policy exists
(https://apollocover.com/privacy-policy), but the security page makes no explicit PIPEDA,
Law 25 or GDPR statement.
evidence:
- source: https://apollocover.com/security
kind: security-posture-page
keywords:
- soc 2 type 2
- iso 27001
- pci dss
- penetration test
- vulnerability management
- incident response
- encryption at rest
- aws kms
- datadome
- guardduty