Rhythm 2.0 Control Catalogue

This catalogue defines the security, confidentiality, privacy, availability, processing integrity and AI obligations for Rhythm's association customers. Specifications cite the applicable control ids; each control's definition has one home here. The statements describe required outcomes, not a claim that implementation or organizational practice already satisfies them. Approval and evidence of operation remain separate from the catalogue.

Applicability follows what the work touches. A relevant control applies; an irrelevant control is omitted. A scanner's vocabulary match prompts human review, and a false match receives an explicit explanation. An applicable control that remains unsatisfied becomes a control-gap finding with an owner, any compensating protection and an expiry. Silence never represents an exception.

The change-management, secret-scanning and vulnerability-management controls that govern every change form the baseline: TC-CHG-001, TC-CHG-002, TC-CHG-003, TC-CHG-004, TC-SEC-001, TC-SEC-004, TC-VUL-001, TC-VUL-002 and TC-VUL-004. Their evidence is collected for the change process rather than repeated in every artifact's applicability list. Other controls apply according to their stated conditions, with privacy applicability determined by personal information, privacy commitments and the specific condition each privacy control names.

Unless a control states otherwise, the Engineering team responsible for the affected area owns it, verification runs whenever the protected behavior changes, and operating evidence is retained for twelve months. A control combining manual and automated activities lists both execution classes. Verification establishes that the control is implemented as designed; the evidence source supplies retrievable proof of its recurring operation. Periodic exercises and checks of externally managed settings retain their own cadence.

TC-IAM — Identity and Authentication

TC-IAM-001 · Attributable Identity for Every Actor

Each person, machine principal, background job and deployment pipeline acts through an identity attributable to one subject. Shared accounts are prohibited, and recorded activity identifies the responsible actor.

TC-IAM-002 · Central Authentication for Human Access

People authenticate through the designated identity provider when they use the staff console, member portal or another Rhythm environment. Applications maintain no independent password store and accept only credentials issued by that provider.

TC-IAM-003 · Multiple Factors for Privileged Access

Rhythm staff and identities with authority beyond one workspace authenticate with a second factor, including cloud and deployment access. MFA for customer users whose authority stays within their workspace remains a product decision. Enforcement is checked after changes and evidenced quarterly because provider settings can change independently of application code.

TC-IAM-004 · Bounded Sessions and Effective Revocation

Authenticated sessions expire within a defined lifetime. Removing an identity or its access stops existing sessions from acting within a documented and tested interval, as well as preventing new sign-ins.

TC-IAM-005 · Credential Validation at Every Boundary

Each receiving trust boundary checks a credential's signature, issuer, audience, expiry and subject before using it for authorization. A caller's claims about itself supply no authority; reliance on validation at an earlier boundary requires an explicit, enforced trust relationship.

TC-IAM-006 · Separate Machine Identities

Lambda jobs, Step Functions workflows and deployment automation use their own machine identities, limited to the work they perform. Automation never borrows a person's credentials, and people never use a job's identity.

TC-AZ — Authorization and Least Privilege

TC-AZ-001 · Declared Permissions for Operations

Every operation that reads, changes or discloses data declares the permission its caller requires in both its specification and implementation. The declaration makes access review and refusal tests possible for every entry point.

TC-AZ-002 · Server Enforcement at Each Operation

The server enforces the operation's required permission on every route to its handler. Hiding an action in the console or portal improves usability but supplies no authorization; direct calls face the same permission check.

TC-AZ-003 · Denied Access on Missing Grants or Errors

A request without a matching grant is refused. Unavailable authorization storage, unreadable claims and unexpected authorization errors also refuse the request, with no permissive fallthrough.

TC-AZ-004 · Least Privilege in Roles and Policies

Product roles and AWS policies name the operations and resources they permit and the reason each grant is needed. Wildcard actions or resources require a recorded justification in the owning specification.

TC-AZ-005 · Separate Platform Authority and Evidence

Cross-workspace actions, platform administration, workspace provisioning or destruction, and access grants require platform authority distinct from workspace authority and produce audit events. Administration of an association's workspace gives no implied authority to administer the platform.

TC-AZ-006 · Access Changes Within a Tested Bound

Grant removal and role changes reach subsequent authorization decisions within a specified, tested interval. Cached decisions and token claims have an explicit maximum age and a revocation path, so stale authority has a bounded lifetime.

TC-TEN — Workspace and Scope Isolation

TC-TEN-001 · Workspace Ownership on Records and Queries

Every workspace-owned record carries its workspace reference, and every read applies that scope below the API. Required ownership constraints and query isolation prevent access from depending on each caller remembering a filter.

TC-TEN-002 · Authorized Workspace Context

The verified principal and the server's access records establish the workspace in which a request may act. A caller-supplied workspace identifier serves only as a lookup key until the server authorizes its use.

TC-TEN-003 · No Disclosure Across Workspace Boundaries

A request for an inaccessible workspace resource returns the same observable answer whether that resource exists or is absent. Messages, status codes, response counts and other observable distinctions reveal no existence information across the boundary.

TC-TEN-004 · Isolation Within a Workspace

Access within a workspace respects narrower grants for organizational units, records and other defined scopes. Membership in the association's workspace alone supplies no authority over all records inside it; the server enforces each applicable boundary.

TC-SEC — Secrets and Credentials

TC-SEC-001 · Secrets Excluded from Published Material

Passwords, API keys, tokens, private keys and credential-bearing connection strings stay out of source, committed configuration, specifications, logs and error responses. Prompts sent to external providers also exclude secrets.

TC-SEC-002 · Managed Secret Storage and Audited Reads

Runtime credentials reside in a managed secret store and enter the application at runtime. Only identities that need a secret can read it, and each access is authorized and logged.

TC-SEC-003 · Rotation and Revocation Without Source Changes

Each long-lived credential has documented rotation and revocation procedures that require no source edit. Rotation is exercised at least annually and whenever exposure is suspected, with the outcome retained as evidence.

TC-SEC-004 · Secret Scans Block Merge

Secret scanning is a required merge check. A detected secret blocks the change from merging instead of leaving an advisory finding that the merge can bypass.

TC-CRY — Encryption and Key Management

TC-CRY-001 · Encrypted Transport

Browser, service, datastore and third-party connections carrying customer information or credentials use current TLS. Endpoints refuse plaintext transport and prevent downgrade to an unencrypted connection.

TC-CRY-002 · Encryption of Durable Data

Aurora Postgres databases, object storage, SQS queues, log groups, backups and snapshots holding customer or confidential information use encryption at rest with managed keys. Each durable store has verifiable encryption settings.

TC-CRY-003 · Controlled Key Management

Encryption and signing keys reside in a managed key service with restricted, policy-authorized use. Rotation is enabled or scheduled, and key administration is separated from permission to read the protected data.

TC-CRY-004 · Vetted Cryptography

Hashing, signing, encryption and random generation use vetted platform libraries and current algorithms. Rhythm defines no cryptographic primitives of its own.

TC-DAT — Data Classification, Retention and Deletion

TC-DAT-001 · Classification of Stored Information

Every table, object prefix, queue payload, log stream and export declares its highest data classification: public, internal, confidential or personal. Confidential information includes association records, uploaded documents and AI request content; personal information identifies an individual. Classification determines the applicable handling obligations.

TC-DAT-002 · Minimum Collection and Transfer

Each collected field serves a stated requirement. Exports and transfers to third parties, including Bedrock model calls, include only the information the operation needs, with the selection and reduction documented in the specification.

TC-DAT-003 · Enforced Retention Periods

Confidential and personal information has a stated retention period enforced by a lifecycle policy or scheduled process. Retention has a defined endpoint independent of whether someone remembers to delete the information.

TC-DAT-004 · Complete and Evidenced Deletion

Customer requests and lifecycle rules remove information through a defined sequence covering primary records, derived data, caches, indexes and object storage. Backup copies are addressed within their stated window. Completion is recorded, and the specification identifies any remaining copies and how long they persist.

TC-DAT-005 · Authorized Customer Export

Where Rhythm commits to export or portability, an authorized association administrator obtains the organization's data in a documented format. Export access is checked, limited to the authorized scope, audited and bounded in time.

TC-DAT-006 · Safe Data in Non-Production Environments

Development, test and demonstration environments use synthetic or anonymized information. Copying confidential production data into these environments requires a recorded exception, and their ordinary credentials provide no production data access.

TC-DAT-007 · Equivalent Protection for Backups

Backups inherit the source information's classification, encryption, access restrictions, retention and deletion obligations. Any difference between backup expiry and a customer deletion commitment is stated explicitly.

TC-LOG — Audit and Security Logging

TC-LOG-001 · Audit Events for Sensitive Actions

Workspace creation, suspension and deletion, permission changes, staff entry into customer workspaces, exports and security-setting changes produce durable audit events as part of the action. Every other platform-level or sensitive action meets the same obligation; audit recording is never best effort.

TC-LOG-002 · Complete Audit Context

Each audit event records the actor, action, affected subject or resource, workspace or applicable scope, outcome and time. Refused attempts are recorded alongside successful actions so the history explains both attempted and completed activity.

TC-LOG-003 · Protected Audit History

Audit history is append-only and tamper-evident. Application paths cannot alter or delete an existing event, and application grants exclude those permissions even when the underlying store technically supports them.

TC-LOG-004 · Security Events for Access Refusals

Refused sign-ins, denied permissions, cross-workspace attempts and malformed credentials produce security events with enough context to detect repeated activity. These events remain distinguishable from ordinary application errors.

TC-LOG-005 · Redaction in Logs and Errors

Application logs, exception traces and caller-visible errors exclude credentials, tokens, personal information and confidential customer content. Errors reveal only information the caller is authorized to receive.

TC-CHG — Secure Change Management

TC-CHG-001 · Versioned Production Changes

Application code, infrastructure, configuration and migrations reach production through version control and deployment. Emergency changes made through the AWS console are incident-response exceptions and are recorded accordingly.

TC-CHG-002 · Independent Review Before Merge

A person other than the author approves each change before it reaches the default branch. Review covers the change's security and control consequences as well as its functional correctness; enforcement settings require verification outside the checkout.

TC-CHG-003 · Protected Default Branch

Repository protection prevents direct pushes, force pushes and merges that bypass required checks on the default branch. Protection settings are evidenced quarterly through external verification.

TC-CHG-004 · Passing Required Checks

Type checking, linting, unit tests, integration tests, secret scanning and dependency scanning pass as required checks before merge. A failing check blocks merge, and an unexecuted check supplies no passing evidence.

TC-CHG-005 · Authorized and Recorded Automation for Deployment

Deployments run through authorized automation and record the commit, target environment, time, initiating identity and outcome. Production deployment authority belongs only to a named set of identities.

TC-CHG-006 · Separate Environments and Credentials

Development, test and production use separate AWS accounts or equally strong isolation boundaries, with separate data, credentials and network paths. Non-production identities have no production access. Cloud account boundaries require external verification.

TC-CHG-007 · Reviewed Migrations and Rollback Position

Every migration receives review as a change to durable customer information. The review states whether it destroys data, and the release explains what happens if application code is rolled back after the migration executes.

TC-VUL — Vulnerability and Dependency Management

TC-VUL-001 · Dependency Scanning and Remediation Windows

Dependency scans detect known vulnerabilities on every change and weekly on the default branch. Critical and high findings have explicit remediation windows; overdue findings become recorded exceptions with accountable owners.

TC-VUL-002 · Required Static Analysis

Each change passes lint and type checks with security-relevant rules enabled. Required checks prevent findings from being bypassed during merge.

TC-VUL-003 · Infrastructure Security Scanning

Infrastructure checks detect unintended public exposure, missing encryption, excessive permissions and missing logging before deployment. Insecure definitions fail checks while the change remains reviewable.

TC-VUL-004 · Tracked Vulnerability Resolution

Vulnerabilities from scans, external reports, incidents and audits enter one tracked list with severity, owner and target date. Monthly review follows each finding through remediation or an explicit exception to closure.

TC-AVL — Availability, Backup and Recovery

TC-AVL-001 · Defined Availability and Recovery Commitments

Rhythm records each availability, durability and recovery commitment in terms an association can validate. The design names the recovery time and recovery point objectives and explains how it meets them.

TC-AVL-002 · Automatic Backups of Authoritative Information

Stores holding information Rhythm cannot reconstruct have automated backups with stated frequency and retention. Backup failure alerts a responder.

TC-AVL-003 · Exercised Restoration

Backup restoration into an isolated environment is exercised at least annually, with the outcome recorded. A successful backup alone supplies no proof of recovery; restoration evidence requires external verification.

TC-AVL-004 · Resumable Durable Work

Long-running work survives process failure through durable checkpoints and resumes from its last committed progress. Step Functions workflows and queued jobs retain a path to advance, recover or settle every customer-visible object after interruption.

TC-AVL-005 · Abuse Resistance on Exposed Operations

Public operations, including sign-in, invitation acceptance, portal registration, upload and export, enforce rate limits or equivalent abuse protection. Exceeding the permitted activity is refused and logged.

TC-MON — Monitoring, Alerting and Incident Response

TC-MON-001 · Monitoring of Deployed Components

Each deployed service, Lambda function, Step Functions workflow and SQS queue has monitoring for availability, errors and latency. Metrics and logs remain available long enough to investigate operational problems.

TC-MON-002 · Addressed Failure Alerts

Each failure alarm states the condition and threshold that trigger it and names its recipient. The destination makes the alert actionable by the person responsible for responding.

TC-MON-003 · Distinct Security Detection and Alerts

Repeated access denials, cross-workspace attempts, unusual privileged actions, credential failures and audit-pipeline failures produce security alerts. These conditions remain distinguishable from routine operational alerts.

TC-MON-004 · Defined and Recorded Incident Response

Incidents follow a documented procedure for detection, triage, containment, communication and closure. Every incident has a record, and the procedure is kept current and exercised. Operational readiness requires verification outside the repository.

TC-MON-005 · Review of Significant Incidents

Each significant incident receives a review recording its cause, impact, timeline and corrective actions. Changes to controls prompted by the incident are included so the response improves subsequent protection.

TC-PI — Processing Integrity

TC-PI-001 · Validation Before Domain Processing

Externally supplied values pass type, range, format and allowed-value checks before domain processing. Invalid input is refused with an explanation that exposes no sensitive information.

TC-PI-002 · One Effect Under Repeated Delivery

Repeated delivery of the same operation produces one effect. A duplicate request or SQS delivery returns the recorded result rather than creating a second record or repeating a customer-visible change.

TC-PI-003 · Visible Concurrent Write Conflicts

Concurrent writers cannot silently overwrite one another's changes. A stale write is refused with an outcome that tells the writer the object has changed.

TC-PI-004 · Reconciliation of Asynchronous Work

Every asynchronous operation completes, fails visibly or enters reconciliation. Scheduled reconciliation detects interrupted jobs, and dead-letter queues retain undeliverable work with alarms, so abandoned execution never resembles success.

TC-PI-005 · Authorized and Attributed State Changes

Objects change state only through permitted lifecycle transitions made by authorized actors. Each change records its actor and any required reason; invalid transitions are refused.

TC-AI — AI Behavior Controls

These controls apply ordinary security, confidentiality, processing integrity and privacy obligations to model boundaries. SOC 2 supplies no AI correctness criterion, and successful validation does not establish the truth of a model response. Every AI feature identifies what the model proposes and what the application decides; provider failure or degradation never lowers validation or required approval.

TC-AI-001 · Application Authority Over Stored State

A model proposes output; the application controls authoritative state and decides what is written after validation. Every resulting change has an application enforcement path that rejects unacceptable values, and output acquires no authority merely by arriving from a model.

TC-AI-002 · Schema Validation of Model Responses

The product parses every structured model response against a declared schema before consuming it. Invalid responses are rejected and handled through a defined failure or fallback path, without coercion or partial authoritative writes.

TC-AI-003 · Business Validation After Model Output

Schema-valid model output still passes the application's business checks for valid references, allowed vocabulary, lifecycle rules and workspace membership. Prompt instructions supply no enforcement, and the model never replaces the application check for a product rule.

TC-AI-004 · Visible Provenance for Derived Content

Model-derived summaries, query suggestions and other presented knowledge record their source material, model, prompt version and creation time. Customers can see that provenance and distinguish derived content from asserted fact.

TC-AI-005 · Recorded Human Approval Where Required

A model-proposed change that requires human approval remains blocked until an identified person approves the relevant version. Approval is recorded, and simply displaying the proposal to a person never satisfies the gate.

TC-AI-006 · Versioned Inference Inputs and Provider Choices

Each inference records its model identifier, provider and prompt or instruction version. Prompts are reviewed source assets. Changing a model or provider receives change review and vendor assessment because downstream behavior depends on that choice.

TC-AI-007 · Controlled Transfers to Model Providers

The specification names the classified information each model provider may receive, the reductions and redactions applied first, and the provider's retention and training terms. Bedrock calls follow those handling rules; a provider processing confidential association information is treated as a subprocessor.

TC-VEN — Vendors, Subprocessors and Integrations

TC-VEN-001 · Reviewed Subprocessors Before Use

A third party that stores, processes or transmits customer information receives security and data-handling review before production use and appears in the subprocessor register. Rhythm discloses that relationship wherever its customer commitments require disclosure.

TC-VEN-002 · Controlled Integration Credentials

Credentials Rhythm holds for integrations, and credentials integrations hold for Rhythm, grant only required access. They reside in managed, restricted storage and can be revoked without changing source code.

TC-VEN-003 · Vendor Support for Customer Commitments

Rhythm's commitments for retention, deletion, confidentiality, residency and breach notification remain within what its subprocessors support. Terms and commitments are compared annually and whenever either side changes.

TC-PRV — Privacy

TC-PRV-001 · Inventory of Personal Information

Each element classified as personal appears in an inventory with its collection purpose, storage location, retention period and recipient parties. The inventory accounts for both stored information and outbound transfers.

TC-PRV-002 · Use Within the Recorded Purpose

Personal information is collected for a purpose stated in a requirement and used within that purpose. A new purpose requires a product decision before engineering introduces the new use.

TC-PRV-003 · Exercised Data Subject Requests

People have a defined, authorized path for access, correction and deletion requests where privacy commitments or regulation require it. Requests are recorded, and the procedure is exercised to prove it can deliver the required outcome.

TC-PRV-004 · Enforced Notice and Preferences

Where notice or consent governs personal information use, the person's preference is stored and checked at the point of use. The person can change that preference, and a prohibited use is refused.

TC-ORG — Organizational Controls

Organizational controls operate outside product code. Their accountable roles maintain the activities and evidence named below, and every control requires external verification. Inclusion here establishes neither implementation nor operating effectiveness; accountable owners establish those facts from evidence. Engineering specifications cite organizational controls wherever their behavior depends on these processes.

TC-ORG-001 · Assigned Security Responsibilities

Executive leadership assigns and documents security responsibilities and reviews them annually. Named roles make accountability for protecting Rhythm and association information explicit.

TC-ORG-002 · Approved and Acknowledged Security Policies

Executive leadership maintains and approves the information security policy set. Staff acknowledge the policies, and policy content and acknowledgement evidence receive annual review.

TC-ORG-003 · Checks Before Access on Hiring

The People function completes background checks where law permits them before a new hire receives access. The completed check and its timing are recorded.

TC-ORG-004 · Recorded Least-Privilege Onboarding

People and Engineering grant a new colleague only the access the role requires. Onboarding records identify the access granted and its basis.

TC-ORG-005 · Timely and Recorded Offboarding

People and Engineering revoke all departing colleagues' access within a stated interval. Timestamped revocation records establish that offboarding reaches every relevant system on time.

TC-ORG-006 · Periodic Review of Production and Customer Access

The Engineering lead reviews access to production systems and customer information quarterly. The record names every account and the decision to retain, change or remove its access.

TC-ORG-007 · Governed Production Access

The Engineering lead defines who may receive production access, the justification required and the activity that is logged. Governance applies continuously, and the access list and logging receive quarterly review.

TC-ORG-008 · Managed Company Devices

IT manages company devices with disk encryption, screen locking, patching and remote wipe. Continuous management records establish coverage and the required protection settings.

TC-ORG-009 · Security Awareness Training

The People function provides security awareness training when colleagues join and annually thereafter. Completion records identify who meets the training requirement.

TC-ORG-010 · Annual Security Risk Assessment

Executive leadership assesses risks to security, confidentiality and availability annually. The assessment identifies each risk and records its rating.

TC-ORG-011 · Tracked Risk Treatment

Executive leadership tracks treatment of identified risks and reviews progress quarterly. Treatment outcomes lead to documented changes in controls where needed.

TC-ORG-012 · Initial and Recurring Vendor Assessment

The Engineering lead assesses vendors and subprocessors before use and annually thereafter. The assessment records their security and data-handling suitability and maintains the subprocessor register.

TC-ORG-013 · Exercised Continuity and Recovery Plans

The Engineering lead maintains business continuity and disaster recovery plans and exercises them annually. Recorded results demonstrate the response to disruption and identify needed improvements.

TC-ORG-014 · Assigned and Exercised Incident Response

The Engineering lead maintains an incident response plan with named roles and exercises it annually. Each incident follows the plan and produces its own response record.

TC-ORG-015 · Monitored Control Effectiveness

Executive leadership monitors control effectiveness quarterly and tracks deficiencies through remediation. Evidence records both identified weaknesses and the actions that address them.

TC-ORG-016 · Agreed Confidentiality Obligations

The People function obtains agreed confidentiality obligations from staff and contractors when their engagement begins. Signed agreements record each person's responsibility to protect confidential information.

TC-ORG-017 · Recorded and Communicated Customer Commitments

Executive leadership documents and communicates commitments for availability, confidentiality, privacy and notification. Changes update the relevant agreements and customer communications.

TC-ORG-018 · Policy for Emergency Changes

The Engineering lead maintains a change management policy covering emergency changes and changes outside the ordinary deployment path. The policy receives annual review, and exceptions retain evidence of the change and its authorization.

TC-ORG-019 · Cloud Management Activity Audit

The Engineering lead ensures cloud management activity and configuration changes are recorded across the AWS estate through CloudTrail and AWS Config or equivalent mechanisms. The records are retained and available for review, with continuous recording and quarterly review of coverage and settings.