Platform Security

ConcertoGRC is built on AWS with security as a foundational requirement -- not an afterthought. This page describes how the platform protects your organization's compliance data across infrastructure, application, and operational layers.

Architecture

ConcertoGRC runs entirely on Amazon Web Services across managed, hardened services:

Layer	Service	Purpose
Compute	ECS Fargate	Serverless containers -- no SSH, no host OS to patch
Database	Amazon RDS (PostgreSQL)	Managed relational database with automated backups
Storage	Amazon S3	Evidence files, exports, and generated reports
CDN	Amazon CloudFront	Edge-cached frontend delivery with TLS termination
Authentication	Amazon Cognito	Identity management and JWT-based session tokens
AI/ML	Amazon Bedrock	AI inference with no data retention by the model provider
Secrets	AWS Secrets Manager	Runtime credential resolution -- no secrets in code or environment variables
DNS	Cloudflare	DNS management with DDoS protection

All services run within a private VPC. The application backend is not directly internet-accessible -- traffic routes through an Application Load Balancer behind CloudFront, with security groups restricting inbound access to expected sources only.

Tenant Isolation

ConcertoGRC is a multi-tenant platform. Every tenant's data is logically isolated at the application layer:

• Every database query is scoped to the authenticated user's organization. There is no API endpoint, background job, or internal function that can return data across tenant boundaries.
• Tenant context is derived from the authenticated JWT -- it cannot be overridden by request parameters or headers.
• File storage is partitioned by organization ID. S3 object paths include the tenant identifier, and pre-signed URLs are scoped to the requesting tenant.
• Background jobs (evidence recalculation, sync schedulers, report generation) process tenants independently and verify tenant context before writing results.
• Audit logging records the acting user and organization for every write operation.

Concerto platform operators can access tenant data for support purposes, but only through authenticated sessions with full audit trail. Tenants can grant and revoke time-limited support access from the Settings page.

Encryption

In Transit

All data in transit is encrypted with TLS 1.2+:

• Browser → CloudFront → ALB → application: TLS at every hop
• Application → RDS: encrypted connections enforced
• Application → S3: HTTPS-only bucket policies
• Application → Bedrock: AWS SDK with TLS
• Application → external integrations (GoPhish, MDM providers, identity providers): TLS-only

At Rest

• Database -- RDS encryption at rest using AWS-managed keys (AES-256)
• File storage -- S3 server-side encryption (SSE-S3) for all buckets
• Secrets -- Stored in AWS Secrets Manager, encrypted with AWS KMS
• Migration credentials -- Encrypted at rest with AES-256-GCM before database storage, decrypted only during active migration sessions
• Integration tokens -- OAuth tokens and API keys encrypted before storage

Authentication

Platform Users

ConcertoGRC uses Amazon Cognito for authentication:

• JWT-based sessions -- Short-lived access tokens with refresh token rotation
• Password policy -- Minimum length, complexity requirements, and breach-password checks enforced by Cognito
• MFA support -- Time-based one-time passwords (TOTP) via authenticator apps
• Session management -- Tokens are validated on every API request; expired tokens are rejected immediately

Employee Portal

The Employee Portal (public-facing for organization employees) uses a separate authentication flow:

• Email OTP -- Employees authenticate with a 6-digit one-time password sent to their work email
• Domain validation -- Only email addresses matching configured allowed domains can authenticate
• Time-limited sessions -- 24-hour bearer token sessions with no persistent cookies
• Personnel linking -- Sessions are linked to the organization's personnel directory; unrecognized emails receive restricted access

External Participants

Tabletop exercise participants and audit firm users authenticate via secure magic links -- single-use, time-limited tokens that do not require platform credentials.

Access Controls

ConcertoGRC uses role-based access control with four tenant roles and two platform roles:

Role	Capabilities
Admin	Full organizational control -- settings, users, data, integrations
User	Read/write access to compliance data -- create, edit, upload
Auditor	Read-only access for audit and review purposes
Executive	Dashboard-focused access for leadership visibility

Every API endpoint enforces role-based authorization. Write operations verify the user has appropriate permissions before processing. Delete operations are restricted to administrators. Sensitive operations (user management, integration configuration, settings changes) require admin role.

Platform operator roles (used by Concerto team members) have additional capabilities but are subject to tenant-level support access grants and full audit logging.

AI & Data Handling

ConcertoGRC uses Amazon Bedrock for AI-powered features including document analysis, risk remediation guidance, report generation, and questionnaire response drafting.

Key data handling commitments:

• No model training on your data -- Amazon Bedrock does not use customer inputs or outputs to train foundation models. Your compliance data is never incorporated into model weights.
• No data retention by the model provider -- Inputs and outputs are processed in real-time and not stored by Anthropic or AWS beyond the request lifecycle.
• AWS region-bound processing -- All AI inference runs within your Bedrock-configured AWS region. Data does not leave the region for processing.
• Tenant-scoped context -- AI prompts include only data from the requesting tenant. Cross-tenant data is never included in AI context.
• Human-in-the-loop -- AI generates drafts and recommendations. No AI output is auto-published or auto-delivered without human review and approval.

AI Features and What Data They Access

Feature	Data Used
Meeting slide generation	Initiative status, evidence metrics, risk scores, incident counts
Questionnaire response drafting	Knowledge Base entries (curated by your team)
Risk remediation guidance	Risk description, scoring, and linked controls
Document analysis	Uploaded document content (certificates, attestations)
Tabletop scenario generation	Organization context you select (vendors, systems, policies)
After-action reports	Exercise responses and observations

Monitoring & Audit Trail

Application Monitoring

• Error tracking -- Application errors are captured with context for rapid diagnosis, without including PII or sensitive data in error payloads
• Infrastructure monitoring -- AWS CloudWatch monitors service health, latency, and resource utilization with alerting thresholds
• Uptime monitoring -- Continuous health checks on all critical endpoints

Audit Logging

ConcertoGRC maintains two audit logs:

Log	Purpose	Retention
Audit Log	Application-level actions -- record creates, updates, deletes, exports, AI generations	Indefinite
Auth Audit Log	Authentication events -- logins, logouts, failed attempts, token refreshes, MFA events	Configurable (default 365 days)

Both logs record the acting user, organization, timestamp, action type, and affected resource. Logs are accessible to tenant administrators from the Administration section and can be exported for external review.

Network Security

• No direct database access -- The database is not publicly accessible. It is reachable only from application containers within the VPC.
• Security groups -- Inbound traffic is restricted at every layer. Only the load balancer accepts external HTTPS traffic; application containers accept traffic only from the load balancer.
• No SSH access -- ECS Fargate containers have no SSH daemon or host-level access. There is no mechanism to shell into a running container.
• Outbound restrictions -- Application containers can reach AWS services, configured integration endpoints, and nothing else.

Secure Development

• Dependency management -- Install scripts are blocked by default (ignore-scripts=true). Only explicitly allowlisted packages can run post-install scripts, reducing supply chain attack surface.
• Input validation -- All API inputs are validated with schema-based validation (Zod) before processing. Invalid payloads are rejected at the boundary.
• SSRF prevention -- User-supplied URLs (webhooks, integration endpoints) are validated against allowlists. Internal network addresses are blocked.
• SQL injection prevention -- All database access uses parameterized queries via Prisma ORM. No raw SQL is constructed from user input.
• XSS prevention -- React's default output escaping, combined with Content Security Policy headers, prevents cross-site scripting.

Business Continuity

• Automated backups -- RDS automated daily snapshots with point-in-time recovery
• Infrastructure as Code -- All infrastructure is defined in AWS CDK, enabling rapid recovery and environment reproduction
• Deployment safety -- Database migrations are validated in CI before deploy. Failed migrations halt the deployment automatically, preventing partial state.

Compliance

ConcertoGRC is built to meet the requirements of the frameworks it helps customers manage. The platform's own security controls are aligned with:

• SOC 2 Type II -- Trust Services Criteria for security, availability, and confidentiality
• ISO 27001 -- Information security management system controls
• HIPAA -- Technical safeguards for protected health information (for healthcare customers with BAAs)

For current certifications, attestation reports, and security documentation, visit the ConcertoGRC Trust Center.

Responsible Disclosure

If you discover a security vulnerability in ConcertoGRC, please contact us at security@concertocompliance.com. We take all reports seriously and will respond within 48 hours.