Security

Wolfmates LLC

Security Policy, last updated September 19, 2025.

Wolfmates Security Policy

Contact: security@wolfmates.com | privacy@wolfmates.com

1) Our commitment

Wolfmates builds software and coordination tools families and organizations can trust. Security is embedded into our architecture, processes, and daily operations—guided by least-privilege access, defense-in-depth, and privacy-by-design.

Wolfmates is not a medical provider. We protect wellness and coordination data to high standards, but the platform is not intended to store regulated medical records unless agreed in writing (e.g., via a BAA).

2) Compliance posture

  • Privacy laws: We design controls to support U.S. state privacy laws (CA/VA/CO/CT/UT) and GDPR principles for international users. See our Privacy Policy for data rights.

  • Payments (PCI): Card transactions are handled by Stripe (PCI DSS Level 1). Wolfmates never stores full PAN data.

  • HIPAA: By default, Wolfmates is not a HIPAA Business Associate. If your use case requires HIPAA alignment, contact us to explore a separate BAA and restricted features.

3) Hosting & infrastructure security

  • Cloud provider: The Wolfmates production environment is hosted on Amazon Web Services (AWS) in [region(s): e.g., us-east-1 / us-west-2]. AWS facilities maintain industry certifications (e.g., ISO 27001, SOC reports) and 24×7 physical controls.

  • Network segmentation: Production services are isolated in VPCs with security groups, restricted egress, and least-privilege IAM policies.

  • Secrets & keys: Encryption keys are managed via AWS KMS. Application secrets are stored in AWS Secrets Manager/SSM Parameter Store with rotation and access logging.

4) Data protection & encryption

  • In transit: TLS 1.2+ (preferring TLS 1.3) for all client–server and service-to-service traffic. HSTS enforced on public endpoints.

  • At rest: AES-256 encryption for databases, object storage, and backups.

  • Tenant separation: Logical separation by account/organization; access to tenant data requires authenticated, authorized context.

  • File handling: Uploaded documents (e.g., PDFs, images) are virus-scanned and stored in private buckets with signed-URL access.

5) Identity, access & device security

  • RBAC: Role-based access controls within the app; least-privilege by default.

  • Admin access: Production access is limited to a small on-call engineering group via MFA-protected SSO; access is logged and reviewed.

  • Customer controls: Support for MFA, session timeouts, and permissioned sharing among family/organizational members.

  • Workstations: Company devices use full-disk encryption, automatic screen-lock, endpoint protection, and OS patch baselines.

  • Change management: All code changes flow through peer review, automated testing, and CI/CD with signed artifacts and restricted deploy roles.

6) Application security

  • Secure SDLC: Threat modeling for new features, dependency scanning (SCA), SAST/DAST in CI, and code review with security checklists.

  • Dependency hygiene: Automated alerts for CVEs; critical vulnerabilities triaged with defined SLAs.

  • Authentication: Modern hashing for credentials; optional SSO/OAuth where available.

  • Rate limiting & abuse: API and login rate limits, bot detection signals, and anomaly throttling protect against brute force and misuse.

  • Input handling: Validation and output encoding to mitigate OWASP Top 10 risks (XSS, injection, CSRF, IDOR, etc.).

7) Logging, monitoring & alerting

  • Telemetry: Centralized application and access logs, immutable storage, and time-synced events.

  • Monitoring: Infrastructure and application health monitored continuously with automated alerts for availability, latency, error rate, and security events.

  • Retention: Security logs retained per legal and operational need ([e.g., 12–24 months]); access is restricted and audited.

8) Backups, availability & disaster recovery

  • Backups: Encrypted backups of primary data stores run on a scheduled cadence ([e.g., hourly incrementals + daily full]) with periodic restore tests.

  • Redundancy: Critical services are deployed across multiple availability zones.

  • Objectives: Target RPO [e.g., ≤ 12 hours] and RTO [e.g., ≤ 24 hours] for core services.

  • Continuity: Runbooks document failover, restore, and degraded-mode operations.

9) Incident response

  • Plan: Formal incident response (IR) playbooks cover detection, triage, containment, eradication, recovery, and post-mortem.

  • Escalation: Severity-based paging to engineering and leadership; customer communications coordinated via established channels.

  • Notification: We notify customers and/or regulators of security incidents as required by applicable law and contractual commitments.

10) Third-party risk & integrations

  • Vendor review: Security and privacy diligence for critical vendors (hosting, telephony/SMS, analytics, error monitoring, email, payments). Contracts require appropriate safeguards and data use limits.

  • Integrations: Where OAuth/SSO is supported, we request the minimum scopes needed and never store your third-party passwords. You can revoke access at any time from the third-party provider.

11) Employee & contractor safeguards

  • Screening & onboarding: Background checks as permitted by law, confidentiality agreements, and role-specific access provisioning.

  • Training: Mandatory security and privacy training at hire and annually (password hygiene, phishing, data handling, incident reporting).

  • Separation: Rapid off-boarding, credential revocation, and asset return/removal.

12) Responsible disclosure

We welcome reports from security researchers. Please email security@wolfmates.com with details and reproduction steps. Do not access data that isn’t yours or impact service availability. We’ll acknowledge receipt, investigate, and keep you updated. Where lawful, we permit good-faith research under this policy.

13) Customer responsibilities

Security is shared. Customers should:

  • Use strong, unique passwords and enable MFA;

  • Manage roles/permissions appropriately;

  • Review audit logs and connected integrations;

  • Keep endpoint devices patched and protected;

  • Avoid uploading unnecessary sensitive data.

14) Data retention & deletion

We retain personal data only as long as needed for the purposes described in our Privacy Policy and to meet legal obligations. Organization admins may request exports and deletions; upon verified request, we delete data from active systems and schedule removal from backups per our retention schedule.

15) Status & changes

We may improve or update this Security Policy from time to time. Material changes will be communicated via in-app notice or email and reflected by the “Last updated” date above.