1. Our approach
Security is foundational to how areturnz handles returns. Brands trust us with order data, end-consumer details, and the physical custody of merchandise. This page describes the technical and organizational measures we use to protect that trust. It is the public summary of the practices referenced in our Data Processing Addendum (Annex II).
We follow a defense-in-depth model: minimize what we collect, separate what we store, encrypt what we keep, log what we do, and verify it with independent reviews.
2. Compliance and frameworks
Our program is built against the controls in SOC 2, ISO/IEC 27001, NIST CSF, and the requirements of GDPR, UK GDPR, and the CCPA/CPRA. We are also designed to support customers operating under PCI DSS (we do not store cardholder data — payments are handled by PCI-certified processors) and HIPAA-adjacent workflows where applicable.
We are actively pursuing independent attestation. We will use commercially reasonable efforts to obtain a SOC 2 Type II report (or comparable third-party certification) and will make a summary available to customers under NDA once issued. Until then, we share our internal control documentation and questionnaire responses on request to support@areturnz.com.
3. Infrastructure and hosting
Production workloads run on Amazon Web Services in the United States. We use managed services where possible (RDS for MySQL, ECR for container images, App Runner for the API tier, Amplify for static frontends, Secrets Manager for credential material) to inherit the security posture of the underlying provider.
- Tenant isolation — every request is scoped by a tenant identifier (
tid) extracted from a signed JWT at the API edge; database queries are filtered at the service layer to prevent cross-tenant access. - Surface separation — the internal operator API and the customer-facing API live behind distinct OAuth scopes; a token issued for one surface is rejected on the other.
- Environment separation — development, staging, and production run in separate AWS accounts with no shared credentials.
4. Data encryption
- In transit — TLS 1.2 or higher for all public endpoints, with HSTS and modern cipher suites. Internal service-to-service traffic is encrypted within the AWS network.
- At rest — AES-256 for primary databases, object storage, backups, and disk volumes. Key material is held in AWS KMS with rotation enabled.
- Secrets — database connection strings, JWT signing keys, and integration credentials are stored in AWS Secrets Manager and injected at deploy time. Source code does not contain secrets.
5. Access control
- Single sign-on for staff access to internal systems with mandatory multi-factor authentication. Hardware security keys are supported and required for privileged roles.
- Least privilege — access is granted by role, not by individual; production database access is restricted to a named on-call rotation and requires audit-logged break-glass approval.
- Quarterly access reviews — user lists are reconciled against HR records; departing personnel are de-provisioned within one business day.
- Customer-side controls — customer admins can manage user roles, sub-account scopes, and API key rotation from the dashboard.
6. Application security
- Secure SDLC — every change is reviewed by a second engineer before merging; high-risk areas (auth, billing, tenancy) require a security reviewer.
- Static and dependency scanning — automated checks on every pull request, with known-vulnerability dependencies blocked from merge.
- Container hardening — multi-stage builds, non-root users, minimal base images, signed images in ECR.
- Penetration testing — we engage independent testers for an annual external assessment and on material architectural changes; remediation is tracked to closure.
- Vulnerability management — severity-driven SLAs: critical within 7 days, high within 30, medium within 90.
7. Network security
- Private VPC with public ingress only through managed load balancers and a Web Application Firewall.
- Managed DDoS protection at the edge.
- Egress is restricted to known destinations (carrier APIs, payment processors, observability vendors).
- Administrative interfaces are not exposed to the public internet.
8. Logging and monitoring
Application logs, access logs, and audit events are centralized and retained for a minimum of 13 months. We monitor for authentication anomalies, unusual data-export patterns, and known indicators of compromise. Alerts page our on-call engineer 24×7.
9. Incident response
We maintain a written incident response plan with defined severity levels, on-call rotations, and post-incident review. For confirmed Security Incidents involving Customer Personal Data, we will notify affected Customers without undue delay and in any event within 72 hours of becoming aware, in accordance with our DPA.
Customers are notified through the email on file for the account owner; for severe incidents we will also post a notice in the dashboard and on our status page.
10. Backups and business continuity
- Automated daily backups of primary databases with point-in-time recovery enabled.
- Backup encryption using the same AES-256 standard as primary data, with keys held separately from production credentials.
- Restore testing performed at least quarterly to validate recoverability.
- Disaster recovery — target recovery point (RPO) of 24 hours and recovery time (RTO) of 8 hours for the primary database tier; lower targets available under custom Order Forms.
11. Personnel security
- Pre-employment background checks where lawful.
- Written confidentiality and acceptable-use agreements signed before access is granted.
- Mandatory security and privacy training at hire and annually thereafter.
- Role-specific training for engineers (secure coding) and warehouse personnel (chain-of-custody, restricted goods handling).
12. Physical security
Cloud infrastructure inherits the physical controls of AWS data centers (access-controlled, 24×7 monitoring, audited under SOC 2, ISO 27001, and others).
Our returns processing facility in East Hanover, NJ uses badge-controlled access, CCTV with retention, visitor logging, segregated zones for high-value and restricted merchandise, and chain-of-custody tracking from inbound carrier scan through final disposition.
13. Vendor and sub-processor management
We perform risk-tiered due diligence on vendors that touch Customer Data, including review of their security posture, certifications, and contractual data-protection terms. The current list of sub-processors is available on written request to support@areturnz.com as described in our DPA.
15. Reporting a vulnerability
We welcome reports from independent researchers. If you believe you have found a security issue in our products or infrastructure, please email support@areturnz.com with “Security report” in the subject line and include:
- a description of the issue and its impact;
- steps to reproduce, including any proof-of-concept;
- any relevant URLs, accounts, IPs, or timestamps; and
- your preferred contact method.
We commit to acknowledging your report within two business days, investigating in good faith, and keeping you informed of progress. Please give us a reasonable opportunity to remediate before public disclosure, and avoid actions that could harm our users or data (no automated scans against production, no social engineering of staff, no privacy violations).
16. Contact
For questions, concerns, security questionnaires, or to request our control documentation, please contact us: support@areturnz.com