Compliance

rag-sample is a personal demo. It has no compliance scope: no regulated data, no customers, no contractual obligations, no audit. This page exists so that fact is recorded, and so the deltas are obvious if the product status ever changes.

Today

Framework	Applies?	Why
SOC 2	No	No customers; no service commitments.
HIPAA	No	No protected health information in the corpus or in user input.
GDPR	No	No identified data subjects; no personal data processed. The /query input is treated as public (data classification).
PCI DSS	No	No payment data anywhere in the system.
FedRAMP	No	Not deployed for a US-federal customer.
AWS Acceptable Use Policy	Yes	Implicit on all AWS usage; no specific obligation triggered.
AWS Bedrock terms	Yes	Default Bedrock data-handling applies (no model-training use of prompts/completions under default settings).
Third-party license: Apache-2.0 on the corpus	Yes	Attribution requirement is satisfied in architecture/overview and the corpus row of the data-classification table.

What changes if scope expands

These are the deltas, not a full compliance playbook. Each is a project, not a checklist.

If a real user base appears (SOC 2 direction)

• Authentication on /query, audit trail of who asked what.
• Customer-managed KMS keys on Aurora and Secrets Manager; key rotation policy.
• Documented change-management process beyond “the GitHub Environment gate” (Prod approvers, separation of duties).
• Documented access-management process for the AWS account.
• Vendor management for Hugging Face, AWS Bedrock, GitHub Actions.
• Backup, restore, and DR runbooks with tested RPO/RTO.
• Incident response runbook (already a gap in the assessment).
• Logging beyond 30 days (RAG008 retention floor must be revisited against the framework’s evidence-retention requirements; typically 1 year).
• Quarterly access review.

If health data enters the corpus or user input (HIPAA direction)

• Bedrock and Aurora must be covered under a Business Associate Agreement with AWS (Bedrock is BAA-eligible; confirm at the time).
• Audit logging of every PHI access; CloudWatch is not sufficient out of the box.
• Encryption with customer-managed keys end to end.
• Minimum-necessary access on the operator’s IAM identity.
• BAAs with any sub-processor that touches the data.
• The “public corpus” stance is dead the moment health data is loaded; the classification rule applies.

If EU users enter scope (GDPR direction)

• Lawful basis for processing recorded; privacy notice on the SPA.
• Data subject rights pipeline: access, deletion, portability. With pgvector + embeddings derived from source text, deletion has to cascade from source row to chunks to embeddings.
• Data Processing Addendum with AWS (Bedrock, Aurora, CloudWatch).
• Cross-border transfer assessment (current region is us-east-1).
• Logging review: questions in CloudWatch can contain personal data; retention and access need to match the lawful basis.

If payment data enters scope (PCI DSS direction)

The architecture does not support this without significant rework (Lambda outside VPC, public RDS Data API, public /query). Treat any addition of cardholder data as a re-platforming, not a configuration change.

Evidence

There is no evidence to collect today because there is no scope. If scope is added, this section becomes the index of automated evidence sources (AWS Config rules, Security Hub findings, CloudTrail exports, IAM Access Analyzer reports). None of those are provisioned today; they are deferred under the same near-zero-cost posture as the rest of the stack.