1. Purpose and scope
This guide describes how customer administrators should configure the Concourse Platform to operate it securely. It applies only to the Concourse Platform; it does not describe Concourse’s internal controls, which are documented in the SOC 2 Type II report available through the Concourse Trust Center. Questions: security@concoursetech.com.
2. Shared responsibility
Concourse operates and secures the platform infrastructure, application code, encryption in transit and at rest, and platform-level monitoring. Customers are responsible for the configuration choices this guide covers: who can access their tenant, what roles those users hold, what data they publish through public-facing portals, what third-party integrations they enable, and how their workflows route sensitive information.
3. Identity and access management
Recommended baseline: least privilege, verified sign-in, no shared accounts.
- Single sign-on. Federate your agency identity provider via SAML 2.0 or OIDC (including Azure Entra ID and Google Workspace). Federation is configured with Concourse during deployment by exchanging identity provider metadata; contact your Concourse deployment lead to set it up. Prefer SSO over password accounts so joiner/leaver processing in your IdP governs platform access.
- Password accounts. Where SSO is not used, accounts are provisioned by invitation with a temporary password. Because platform-level MFA is not available for these accounts, they must not be assigned privileged or administrative roles.
- Multi-factor authentication. Require phishing-resistant MFA in your identity provider for every workforce and privileged user. Federal administrative access must use federated SSO; Concourse relies on the identity provider to enforce MFA.
- Role-based access control. The platform is multi-tenant with role-based access for internal and external users. Assign the least-privileged role that supports each user’s duties; restrict administrator roles to named individuals, never shared mailboxes. Review role assignments at least quarterly.
- External users. Public-portal accounts (applicants, residents) must never hold internal roles. Audit any account with cross-boundary access.
4. Public-facing portals
- Publish only records approved for public release; portal content is internet-visible by design.
- Configure form submissions so that submitted personally identifiable information is routed to restricted queues, not to broadly readable workspaces.
- Access to shared plan and ticket views is by revocable tokenized links; treat share links as credentials — scope them to the intended recipients and revoke them when staff or stakeholders leave.
- Public endpoints enforce per-IP rate limits and per-deployment origin allowlists, and all traffic is served over TLS on Concourse-managed domains.
5. Workflow automation and notifications
- Review automated notification templates so they do not embed sensitive record content in outbound email; prefer “a record requires your attention” links over inlined data.
- Restrict who can create or modify workflow rules — workflow edit rights are effectively data-routing rights.
6. Documents and records
- Apply access controls at the folder or record-type level before loading documents; retrofitting permissions after bulk upload risks a window of overexposure.
- Retention is managed by Concourse under fixed lifecycle windows by data class and is not customer-configurable. Review the applicable retention schedule during onboarding and arrange any legal-hold, export, or longer-retention requirements before production use.
7. Integrations and API access
- Create a dedicated credential per integration; never reuse one credential across systems. Integration tokens are issued per deployment, stored only as hashes, shown once at issuance, and can be rotated in place and revoked; issuance and rotation are recorded in the audit log.
- Scope credentials to the minimum the integration needs: personal access tokens carry explicit scopes that are intersected with the holder’s live role grants on every request, can be restricted to specific deployments, and read-only scopes refuse write operations. Rotate credentials on a defined schedule and on personnel departure, and store them in your agency’s secrets manager — never in shared documents.
- Disable integrations that are no longer in use.
8. AI-assisted capabilities
- AI model hosting and inference arrangements are configured per deployment to meet your agency’s requirements.
9. Logging and monitoring
- The platform maintains an append-only audit log of authenticated actions, capturing actor identity (including any impersonation), before-and-after values, and reads of personally identifiable information. Administrators holding the audit-log permission can filter it by date, actor, and action, and export it to CSV from Settings → Audit Log. Grant that permission deliberately, and review the log as part of your agency’s continuous-monitoring program.
- Tenant audit events remain searchable for 12 months and are retained in encrypted archival storage for an additional 18 months. Agencies requiring longer retention should export audit events to their designated security or records system.
10. Reporting a security issue
Report suspected vulnerabilities or security incidents to security@concoursetech.com. Vulnerability disclosure policy, scope, and safe-harbor terms: concoursetech.com/bugbounty.
Document owner: Concourse Security Team · Maintained by: Concourse GRC Team · Questions: security@concoursetech.com