Evaluating Flexday AI
How the platform supports your compliance
Platform mechanisms mapped to SOC 2 trust services criteria, ISO/IEC 27001:2022 Annex A and GDPR, and what stays with you or with Flexday.
Written for
- Functional users
- Technical
Last reviewed
Your auditors will ask how a new platform affects the controls you already report on. This page maps Flexday AI's mechanisms to three frameworks buyers use most: the SOC 2 trust services criteria, ISO/IEC 27001:2022 Annex A, and the GDPR. Each row names the mechanism, links to the page that explains it, and says what stays with you or with Flexday as a company.
Important
This page describes platform capabilities. It is not a certification, an attestation or an audit opinion, and it does not say that Flexday or your use of Flexday AI meets any framework. Ask Flexday for its current third-party attestation reports, if it holds any (for example SOC 2), with their scope and period, during due diligence.
How to read the tables
- Platform mechanism is something the product does, described on the linked page and backed by its source code or infrastructure definition.
- Stays with you is the part of the control your organisation still operates, such as reviewing access or deciding retention.
- Ask Flexday marks a control that depends on Flexday as a company (its people, processes and suppliers), which no product page can show. Those items are in the documents to request.
SOC 2 trust services criteria
| Criteria | Platform mechanism | Stays with you, or ask Flexday |
|---|---|---|
| CC6.1 Logical access security | Sign-in through your identity provider, or a user pool the deployment runs (shared, or dedicated to your workspace), enforced by default; every request's token verified, and a token from another workspace's own provider refused; database row-level security between workspaces. See Security overview. | Choosing and running the identity provider, and its multi-factor policy; for a pool the deployment runs, ask Flexday |
| CC6.2 Registering and removing users | Members join by invitation from an owner or admin, or by an owner's email-domain rule, which admits people whose email address is verified; roles are changed and members removed on the Members page; end users of apps are governed by the Solution's Identity. See Identity and access. | Joiner, mover and leaver reviews; removing people from your identity provider |
| CC6.3 Role-based access and least privilege | Four workspace roles; Solution grants; Fact Base database roles and row policies; Agent tools as an explicit allow-list; the runtime gateway on a least-privilege database identity in the AWS reference deployment and the Docker Compose setup. See Data isolation. | Granting the least access each person needs, and periodic access reviews |
| CC6.6 Protection at the boundary | HTTPS on every public address; a web application firewall in the AWS reference deployment; per-endpoint sign-in rules; an Agent's HTTP calls, a Flow's file fetches and business-application calls, and a Doc Base's website crawls refuse private network addresses. See Security overview. | Network rules in a dedicated deployment you operate; the addresses your Flows' HTTP steps call |
| CC6.7 Restricting data in transit and movement | Encrypted connections at the public edge and to the database; files always leave as downloads; exports never carry credentials. See Secrets and encryption. | Deciding which data a Solution may export or send by email |
| CC6.8 Malicious software | Downloads are always attachments with a safe content type; when a scanner is configured, files are served only after a clean verdict. See File safety. | Turning on malware scanning where the deployment offers it |
| CC7.1 Detecting changes and vulnerabilities | Platform changes reach the main branches through pull requests that pass an automated check suite (administrators can bypass the pull-request rule, and a CI job flags a commit pushed straight to the development branch), including database-drift and row-level-security checks; images are scanned when pushed to the AWS image registry. See Security overview. | Ask Flexday: vulnerability and dependency management, and penetration-test results |
| CC7.2 Monitoring for anomalies | An audit trail written by the database, a file access log, a record of every completed model call, and guardrail events in Agent analytics. See Audit, usage and cost. | Reviewing these records; ask Flexday how it monitors the hosted service |
| CC7.3 to CC7.5 Incidents and recovery | Durable background jobs that survive restarts; managed database backups. See Reliability and business continuity. | Ask Flexday: incident response, breach notification and recovery testing |
| CC8.1 Change management | Your changes: drafts, checks, explicit publishing (a new app's first build goes live automatically) and numbered, immutable versions. Platform changes: pull requests, automated checks and database changes applied before services roll. See Change control and versioning. | Approving what your builders publish |
| CC9.2 Vendors and business partners | The list of services the platform can call, each used only when a feature needs it. | Ask Flexday: its sub-processor list and supplier reviews |
| A1.2 Backups and recovery infrastructure | Managed database backups with a retention period set per environment, a final snapshot before a database is deleted, and deletion protection in production. See Reliability and business continuity. | Ask Flexday: availability commitments and recovery objectives |
| C1.1 and C1.2 Confidential information | Audience tags on documents and files; credentials sealed and never exported; soft-deleted files removed for good after the store's retention window, when one is set; ordered deletion of a whole Solution. See Data lifecycle and portability. | Classifying your data and setting retention windows |
| PI1 Processing integrity | Validated inputs and plans applied exactly as shown; outside effects such as emails and ticket writes keyed so a retry does not repeat them. See Reliability and business continuity. | Checking the outputs of your own Flows and Agents |
ISO/IEC 27001:2022 Annex A
Annex A groups its controls into four themes. The platform supports controls in the organizational and technological themes. The people and physical themes are about Flexday as a company and its cloud providers, so they are things to ask for.
| Theme and control | Platform mechanism | Stays with you, or ask Flexday |
|---|---|---|
| Organizational: 5.15 Access control, 5.18 Access rights | Workspace roles and Solution grants, with optional expiry dates; owners and admins can always reach every Solution, so nothing is stranded | Your access policy and its reviews |
| Organizational: 5.16 Identity management, 5.17 Authentication information | People are identified by your identity provider, or by a user pool the deployment runs; Flexday AI's own database stores no builder passwords; machine credentials for gateways are stored as hashes or sealed secrets | Your identity provider's lifecycle and password or multi-factor rules |
| Organizational: 5.23 Information security for cloud services | Deployment options from shared hosting to a dedicated deployment in your own cloud account. See Deployment options and data residency. | Ask Flexday: its cloud provider agreements |
| Organizational: 5.33 Protection of records | The audit trail is written by database triggers, not by application code that could skip it | Retaining and reviewing audit records you export |
| Organizational: 5.34 Privacy and protection of personal data | The data inventory, personal-data guardrails and audience tags described in Data protection and privacy | Your records of processing and lawful bases |
| People: 6.1 to 6.8 | Not a platform function | Ask Flexday: staff screening, training and confidentiality terms |
| Physical: 7.1 to 7.14 | Not a platform function; the platform runs in managed cloud data centres | Ask Flexday: its cloud providers' physical security reports |
| Technological: 8.2 Privileged access rights | Flexday staff use a separate console with their own roles; support access to your workspace is possible only while its Support access setting is on (it is on unless an owner turns it off), is read-only unless staff choose write access when starting it, and is recorded against the staff member. See Platform operations. | Deciding when to allow support access |
| Technological: 8.3 Information access restriction | Database row-level security between workspaces; Solution grants; Fact Base row policies; audience tags | Designing row policies and tags for your data |
| Technological: 8.5 Secure authentication | Enforced sign-in by default; tokens checked on every request against the identity provider the workspace signs in with, and a token from another workspace's own provider refused | Multi-factor and conditional access in your identity provider |
| Technological: 8.7 Protection against malware | Attachment-only downloads and, when configured, scanning before a file is served | Enabling scanning where offered |
| Technological: 8.10 Information deletion, 8.11 Data masking | Deleting rows, documents, files and whole Solutions; personal-data masking in Agent conversations when switched on | Deciding what to delete and when; switching masking on |
| Technological: 8.12 Data leakage prevention | Secrets never returned or exported; files never served as pages; an Agent's outbound calls limited to allow-listed addresses | Choosing what each Agent and Flow may send out |
| Technological: 8.13 Information backup | Managed database backups with per-environment retention | Ask Flexday: backup testing and recovery objectives |
| Technological: 8.15 Logging, 8.16 Monitoring activities | Audit trail, file access log, usage records, Agent analytics, Flow run history | Reviewing the records |
| Technological: 8.24 Use of cryptography | Encrypted storage for the database and objects; credentials sealed per workspace; Secret Variables sealed under the workspace's own key, or in the cloud's vault where the deployment is set to use one, and kept apart per workspace. See Secrets and encryption. | Choosing a dedicated deployment if secrets must live in your own cloud account |
| Technological: 8.25 Secure development life cycle, 8.28 Secure coding, 8.32 Change management | Pull requests with automated checks, build actions pinned to exact commits and a check for code that would write credentials to logs, for the platform; drafts and versions for what you build | Ask Flexday: its secure development policy |
GDPR
Under the GDPR your organisation is usually the controller of the personal data in its Solutions, and Flexday a processor. Several articles below are therefore your obligations; the platform gives you the means to meet them.
| Article | What it asks | How the platform helps | Stays with you, or ask Flexday |
|---|---|---|---|
| 5 Principles | Purpose limitation, minimisation, storage limitation, integrity, confidentiality, accountability | One Solution per purpose, with every resource it may reach inside it; you choose what data to load; retention rules for files; encryption and access control; an audit trail | Deciding purposes, what to collect and how long to keep it |
| 17 Right to erasure | Erasing a person's data on request | A saved query can delete a person's rows, and a Fact Base's data can be cleared; documents and files can be deleted outright, or soft-deleted and removed for good after the File Store's retention window when one is set (none is by default); a whole Solution can be deleted. Copies remain in database backups until they age out, and the audit trail keeps what the platform's audited records held (Fact Base rows are not audited) | Finding a person's data across your Solutions, and handling each request |
| 20 Right to data portability | Giving a person their data in a machine-readable format | Fact Base data is queryable with SQL and can be returned in a structured format through a saved query or an export bundle | Responding to requests |
| 25 Data protection by design and by default | Protective defaults | Sign-in enforced by default; Agents get no tool until granted; File Store write access never implied; a separate record of form submissions kept only if switched on (the answers stay in the conversation either way); personal-data guardrails | Configuring each Solution to your policies |
| 28 Processor | A contract with the processor, with sufficient guarantees | A dedicated deployment keeps the platform's own services and storage in your cloud account; the services it can call outside it, such as the AI model provider the Builder always uses, are listed | Your obligation as controller: ask Flexday for its data processing agreement and sub-processor list |
| 30 Records of processing | A record of each processing activity | The data inventory describes what the platform holds, where and for how long | Keeping your own record |
| 32 Security of processing | Appropriate technical measures | Encryption, isolation enforced by the database, access control, backups, and an audit trail | Ask Flexday: its security testing and incident process |