Security & Compliance Overview

1. Executive Summary

Teamworks is a multi-tenant SaaS volunteer-management platform hosted on Amazon Web Services in the United States. The platform is designed around four security principles:

1. Tenant isolation by default — every record in the system is scoped to an organization and enforced at the data-access layer.
2. Federated identity — authentication is delegated to a dedicated identity provider; the application never stores end-user passwords.
3. Least privilege — production access is limited to short-lived, role-assumed credentials issued via OIDC federation; no long-lived cloud access keys exist.
4. Defense in depth — multiple independent controls (network segmentation, encryption in transit and at rest, application-level authorization, audit logging) protect customer data.

2. Company & Product

3. Architecture

Teamworks is composed of three deployable surfaces and one external identity service. Key design decisions affecting security:

• The API and database run in private network segments with no direct internet exposure; only the public load balancer is internet-reachable, and it accepts inbound traffic only from the upstream CDN's managed IP ranges.
• The Web SPA and API share an origin (teamworks.r2it.com), eliminating CORS exposure.
• TLS terminates at the CDN edge and is re-encrypted on the internal hop to the API; database connections are TLS-encrypted end-to-end.
• The identity provider is deployed and operated as a separate service (login.r2it.com) — a compromise of the API does not yield credentials, only short-lived access tokens.

A sanitized architecture and data-flow diagram is available to customers under NDA.

4. Identity & Access Management

End-user authentication

• All sign-ins go through the identity provider at login.r2it.com using OpenID Connect with the Authorization Code + PKCE flow.
• The Teamworks API validates every request via a signed JWT bearer token; tokens are short-lived and rotated via refresh tokens.
• Teamworks never stores end-user passwords. Password policy, MFA enrollment, and recovery flows are handled by the identity provider.
• Configurable password complexity, breach-detection blocklists, and TOTP-based MFA are enforced at the IdP.
• A household-account model supports multiple "Person" profiles under a single login, gated by a per-profile PIN stored as PBKDF2-SHA256 with a 5-attempt / 15-minute lockout window.

Authorization model

Authorization is enforced in the API layer on every request via a layered model:

Every database query for tenant-scoped entities is filtered by org_id at the data-access layer through a global query filter, ensuring cross-tenant reads are impossible even if an authorization check is missed in application code.

Administrative access

• Production cloud access is restricted to named R2IT engineers via SSO-federated roles.
• CI/CD pipelines assume per-environment deployment roles via OIDC federation — no long-lived cloud access keys exist in CI or on engineer laptops.
• Production deployments require manual approval; staging deploys automatically from the trunk branch.
• Direct database access in production is brokered through an ephemeral admin task with credentials sourced from a managed secrets store; no shared database passwords are distributed.

5. Tenant Isolation

Teamworks is logically multi-tenant — all customers share the same application and database, with isolation enforced in software.

1. Every tenant-scoped entity carries an org_id column.
2. Data-access-layer global query filters enforce org_id matching on every read.
3. Authorization middleware resolves the caller's effective OrgMembership and EventMembership per request from the JWT subject claim.
4. Integration tests exercise cross-tenant access attempts as part of the test suite.

Customers with single-tenant data-residency requirements should contact R2IT to discuss a dedicated deployment.

6. Data Protection

Encryption in transit

• All public traffic uses TLS 1.2 or higher, terminated at the CDN edge.
• Internal traffic from the CDN to the load balancer uses TLS.
• Database connections from the API to the managed database use TLS.
• Email delivery uses STARTTLS over port 587 to SendGrid's SMTP relay.

Encryption at rest

• Database storage is encrypted at rest using cloud-provider-managed KMS keys (AES-256).
• All automated database backups and snapshots are encrypted.
• Object storage holding static assets is encrypted at rest.
• Managed secrets-store entries (database connection strings, SMTP credentials, identity-provider admin secrets) are KMS-encrypted.
• Sensitive credentials (PINs) are stored as PBKDF2-SHA256 hashes; raw values are never stored.

Data categories collected

Teamworks does not collect or store Social Security numbers or other government-issued identifiers (other than driver's license numbers where required by a role), full payment card numbers, biometric identifiers, or geolocation data beyond shift check-in events.

Data retention

• Operational data is retained for the life of the customer's subscription plus 30 days post-termination, during which exports may be requested.
• After 30 days post-termination, customer data is purged from production systems within 60 days.
• Automated database backups have a 30-day retention window; backups are deleted on schedule.
• Audit logs are retained for 12 months.
• Customers may request earlier deletion of specific records subject to legal retention requirements.

7. Audit Logging & Monitoring

• Every create, update, and delete across business entities is captured in an application-level audit log by a data-access-layer interceptor. The log records entity type, primary key, action, before/after diff (JSON), acting Person, and a UTC timestamp.
• Cloud-provider infrastructure events (identity, compute, database, storage, and secrets access) are logged to the provider's audit-log service.
• Application logs and request metrics are shipped to a centralized log service.
• Alarms exist on health check failures, unhandled exception rates, and unusual error volumes.
• Customer-visible activity timelines are rendered from the audit log on volunteer and assignment detail pages.

A dedicated SIEM and 24/7 SOC are not currently in place; alerting is routed to the R2IT on-call engineer.

8. Software Development Lifecycle

• Source control: hosted Git, with branch protection enforced on the trunk branch.
• Code review: All changes to production code require pull-request review before merge.
• Static analysis: compiler warnings are treated as errors; null-safety is enforced project-wide.
• Dependency management: all dependency versions are pinned centrally; an automated scanner raises PRs for security advisories.
• Testing: Domain logic is covered by an automated unit-test suite; persistence and handler integration tests run against ephemeral database containers on every CI build.
• CI/CD: Pipelines build, test, containerize, and deploy via short-lived OIDC-federated cloud roles.
• Secrets: No secrets are committed to source. Production secrets are stored in a managed cloud secrets store and injected at container start.

9. Vulnerability Management

• OS and runtime patching is handled by the cloud provider — container images are rebuilt from upstream minimal base images on every release; the managed database is on a minor-version auto-upgrade track.
• Dependency vulnerabilities are surfaced by an automated scanner and triaged within the engineering team.
• Critical and high-severity CVEs affecting Teamworks are remediated within 30 days; medium within 90 days.
• A formal third-party penetration test is planned for Q4 2026. Customers under NDA may request the summary letter once available.

10. Business Continuity & Incident Response

Backups & disaster recovery

• The managed database has automated daily snapshots with 30-day retention and point-in-time recovery (PITR) within that window.
• The production database is deployed multi-AZ for automated failover within minutes of an availability-zone event.
• Object storage has versioning enabled; CDN-served static assets are reconstructable from the source repository.
• Infrastructure is defined as code and can be re-provisioned to a new region from configuration if required.

Targets (best-effort, not contractual unless specified in a customer agreement):

• Recovery Point Objective (RPO): ≤ 5 minutes (via PITR)
• Recovery Time Objective (RTO): ≤ 4 hours for AZ-level events; ≤ 24 hours for region-level events

Incident response

R2IT maintains an internal Incident Response Plan covering detection, containment, eradication, recovery, and post-incident review. Key commitments:

• Customer notification of confirmed security incidents affecting their data: within 72 hours of confirmation.
• Notification will include the nature of the incident, data categories affected (or potentially affected), remediation actions taken, and recommendations for the customer.
• A post-incident report will be provided within 30 days.

Specific notification timelines for customers subject to state breach-notification laws (e.g., NY SHIELD, CCPA, VCDPA) will be honored per the applicable statute.

11. Compliance Roadmap

Teamworks is not currently certified under any third-party security framework. The following roadmap reflects R2IT's commitments:

Customers requiring evidence of specific controls prior to certification are encouraged to request a control walkthrough.

12. Privacy & Regulatory Posture

• Teamworks operates exclusively in the United States and does not currently process data subject to GDPR.
• The platform is designed to support customer obligations under U.S. state privacy laws including CCPA, New York SHIELD Act, Virginia CDPA, and similar regimes.
• A Data Processing Agreement (DPA) is available on request and is a standard part of enterprise contracts.
• A current list of subprocessors is published at /security/subprocessors.

COPPA note: Teamworks is not directed at children under 13 and does not knowingly collect data from them. Customers using Teamworks for programs involving minors are responsible for obtaining any required parental consent.

13. Resources

The following materials are publicly available. Additional documentation (architecture diagrams, internal IR runbook, pen test summary, DPA template, NDA, full CAIQ-Lite responses) is available to customers under NDA — email security@r2it.com to request.

14. Contact

Security questions, vulnerability reports, or compliance inquiries: security@r2it.com

Privacy questions and data subject requests: privacy@r2it.com

Vulnerability disclosure: We welcome responsible disclosure of security issues. Please do not publicly disclose findings until we have had a reasonable opportunity to remediate.

This document describes current and committed practices as of the version date. It is provided for informational purposes and does not modify or supersede the terms of any customer agreement.