Evaluating Flexday AI
Security questionnaire, answered
Answers to the questions vendor security questionnaires ask, from the platform's code and infrastructure, plus the company documents to request from Flexday.
Written for
- Technical
Last reviewed
Vendor-risk questionnaires ask the same questions in different words. This page answers them from the platform's source code and infrastructure definitions, so each answer describes what the platform does, not what anyone has promised. Every answer has a short form (Yes, No, Configurable or Per deployment), a sentence or two on how it works, and a link to the page with the detail. Questions about Flexday as a company, such as certifications, testing, service levels and contracts, cannot be answered from the product; they are gathered at the end under Documents to request.
Note
"Per deployment" means the answer depends on where the platform runs. Where an answer describes infrastructure, it is the AWS reference deployment that Flexday SaaS runs on. See Deployment options and data residency.
Identity and access
| # | Question | Answer | How it works |
|---|---|---|---|
| IA-1 | Can our staff sign in with our own single sign-on? | Yes | The Studio signs people in through Microsoft Entra ID, Microsoft Entra External ID, Amazon Cognito, or any OpenID Connect or SAML provider. See Identity and access. |
| IA-2 | Can the people who use apps built on the platform sign in with our identity provider? | Yes | A Solution's gateway can check the people and systems calling it against an Identity: 30 provider presets and nine mechanisms, including OpenID Connect and SAML federation. See Identity. |
| IA-3 | Is multi-factor authentication supported? | Configurable | When builders sign in through your own identity provider, multi-factor authentication and conditional access are that provider's to enforce. A workspace that signs in through the shared or a dedicated Amazon Cognito user pool uses a password that Cognito holds, and the platform does not switch on multi-factor authentication for those pools. The platform's own database stores no passwords. |
| IA-4 | Is authentication enforced by default? | Yes | Every Studio API request needs a verified sign-in token unless an operator explicitly switches that off, apart from a few public routes (health checks, the API description, sign-in discovery) and routes that carry their own credential, such as a Flow's signed webhook. A deployment that switches it off prints a warning when it starts. Flexday's environments are configured with sign-in enforced. |
| IA-5 | Is access controlled by role? | Yes | Four workspace roles (Owner, Admin, Member, Viewer) and three Solution roles (Manager, Editor, Viewer). See Identity and access. |
| IA-6 | Can access be limited to individual projects? | Configurable | A Solution grant gives a person access to one Solution. In a Restricted workspace, set by the platform's operators, members and viewers see only the Solutions they hold a grant on; owners and admins still reach every Solution. |
| IA-7 | Can access expire automatically? | Configurable | A Solution grant can carry an expiry date. In a Restricted workspace an expired grant removes that Solution; in an Open workspace, the default, the person keeps the access their workspace role gives. Workspace membership itself does not expire. |
| IA-8 | Can we add and remove users ourselves? | Yes | Owners and admins invite people and remove them on the Members page; an owner can also let verified email domains join automatically, through the platform's API. No automated provisioning protocol, such as SCIM, is offered. |
| IA-9 | Is there a minimum of one owner, and who can create owners? | Yes | Inside the workspace, only owners can make or remove owners, and the platform refuses to remove the last active owner. Flexday support staff can also reset a workspace's owner from the Admin Console. |
| IA-10 | Can systems call the platform without a person signing in? | Yes | Gateway Identities support API keys (stored only as hashes), signed requests, token introspection and, where a deployment enables it, client certificates. |
| IA-11 | Can Flexday staff access our workspace? | Configurable | Staff work inside your workspace only through a support session while your Support access setting is on. It is on by default, an owner can switch it off, and switching it off ends live sessions. Separately, the Admin Console lets staff read the audit trail and member lists across workspaces, change a workspace's plan and lifecycle, reset its owner and change its sign-in setup; that does not depend on the setting, and changes made there are recorded against the staff member. See Platform operations. |
| IA-12 | Can we see when Flexday staff accessed our workspace? | Yes | Owners are emailed when a support session starts, admins see active and recent sessions under Settings, and work in a session is recorded against the staff member. |
Data protection and encryption
| # | Question | Answer | How it works |
|---|---|---|---|
| DP-1 | Is data encrypted in transit over public networks? | Yes | Every public address is HTTPS only, with TLS 1.2 or later; plain HTTP is redirected. See Security overview. |
| DP-2 | Is traffic between internal components encrypted? | Per deployment | Database connections are encrypted. In the AWS reference configuration object storage refuses any request not made over TLS, the load balancer reaches the services over plain HTTP inside the private network, and the cache connection is not encrypted; encrypting it is a setting. |
| DP-3 | Is data encrypted at rest? | Yes | The database, object storage, the shared file system and the cache are encrypted at rest. |
| DP-4 | Who manages the encryption keys? | Per deployment | The database uses a key managed by AWS; object storage and the file system use a KMS key the deployment creates in its own account. |
| DP-5 | Can we supply our own encryption key? | No | Not for the database or object storage in this release. A dedicated deployment creates its keys in your own cloud account (on the Azure reference deployment, Microsoft-managed keys); for secrets, see DP-7. |
| DP-6 | How are stored credentials protected? | Yes | Credentials are encrypted with AES-256-GCM, under a key that belongs to your workspace (itself protected by a platform master key) or, for a workspace's single sign-on client secret and an Identity's on-behalf-of client secret, under the platform key directly. They can be replaced but never read back. See Secrets and encryption. |
| DP-7 | Can secrets be kept in our own vault? | Per deployment | A dedicated deployment can be set to keep Secret Variables in a vault in your own cloud account: AWS Secrets Manager on AWS, Azure Key Vault on Azure. On Flexday's shared service the store is a deployment setting, not a workspace's: as its infrastructure code is configured, Secret Variables are sealed in Flexday AI's encrypted storage under a key that belongs to your workspace, and there is no option to point it at your own vault. |
| DP-8 | Are secrets ever exported or returned by the API? | No | Exports and imports carry a secret's name, never its value, and so does every Template made from a Solution and every Solution cloned from a Template. Publishing a Template to the global catalog, which only the deployment's default workspace can do, keeps a frozen copy, credentials included, inside that workspace; a workspace that clones it gets none. The API never returns a stored credential. |
| DP-9 | Are uploaded files scanned for malware? | Configurable | Amazon GuardDuty and Microsoft Defender for Storage are supported; scanning is off unless a deployment switches it on, and the infrastructure code for Flexday's environments leaves it off. Files always leave with a safe content type, so anything a browser could run is sent as a generic file; files served to apps always download, and only two Studio views (a Doc Base document's preview and a Bot's icon) show a file inline. See File safety. |
Tenant isolation
| # | Question | Answer | How it works |
|---|---|---|---|
| TI-1 | How is our data separated from other customers' data? | Yes | PostgreSQL row-level security keeps each workspace's Solutions and the resources in them apart; records written as the platform runs carry the workspace and are filtered by the application (TI-2); stored objects carry a workspace prefix; each Fact Base has its own database schema. See Data isolation. |
| TI-2 | Does isolation fail closed? | Yes | For records under row-level security, a request or job without a workspace scope sees nothing. Records written as the platform runs, such as usage, the audit trail, run and conversation history and a document's indexed text, carry the workspace too and are filtered by the application. |
| TI-3 | Is isolation tested? | Yes | Automated tests run under the restricted database roles in both directions, a check fails the build if a new table is not classified for isolation, and another fails it if the AWS or Docker Compose setup stops running the gateway that serves apps under its restricted database role. |
| TI-4 | Can we have a dedicated deployment? | Yes | The platform can run as a dedicated deployment in your own AWS account or Azure subscription. See Deployment options and data residency. |
| TI-5 | Can an app or Agent built by one customer reach another's data? | No | References across Solutions are refused when they run, and some already at publish; an Agent's grants are checked to be in its own Solution, and on a workspace apps address the workspace comes from the address itself. |
| TI-6 | Does the runtime that serves apps have broad database access? | No | It connects as a separate least-privilege role, runs saved queries under a Fact Base role, and cannot read datasets directly (the Azure reference Terraform does not yet give it that role). |
| TI-7 | Do generated apps share an origin with the Studio? | No | Apps are served on a separate apps address, so an app cannot use a builder's Studio session. A deployment can give each workspace its own apps address. |
Logging and monitoring
| # | Question | Answer | How it works |
|---|---|---|---|
| LM-1 | Is there an audit trail of changes? | Yes | Database triggers record changes to the platform's audited records, with the person responsible. See Audit, usage and cost. |
| LM-2 | Are actions by your staff in our workspace attributed to them? | Yes | Work in a support session is recorded against the Flexday staff member, never one of your users. |
| LM-3 | Can the audit trail be altered? | No | A database trigger refuses updates and deletes on it. Two operator-run tasks are the only exceptions: purging a whole workspace, and compacting old Builder-conversation entries into a digest (size, SHA-256 fingerprint and message count) after a backup that still holds the originals. A change to the Builder's saved conversation is now recorded as that digest, not as two full copies. |
| LM-4 | Are reads of files logged? | Yes | Each File Store keeps an access log of downloads, previews, listings and links issued: who read the file (a Studio user, or an app user's sign-in reference), through what (the Studio, an app, a Flow or an Agent) and which browser. Opening and listing stored form submissions is logged too. |
| LM-5 | Can we export audit and usage records? | Yes | Usage exports as CSV from the Usage page; workspace admins read the audit trail through the platform's API. |
| LM-6 | Is AI usage recorded? | Yes | Every completed model call is recorded with the model and its token counts, and the usage reports turn those into an estimated cost at list prices; prompt and answer text are not kept in these records. |
| LM-7 | Can monitoring data go to our own tools? | Configurable | The services can export traces and metrics over OpenTelemetry, off unless configured; in a dedicated deployment, logs are in your account's log service. |
| LM-8 | Is the platform monitored with alerts? | Per deployment | The AWS reference deployment raises CloudWatch alarms on the database, services, load balancer, cache and email, sent to notification topics. |
| LM-9 | Is network and DNS activity logged? | Per deployment | The AWS reference deployment sends the network's flow logs, the web application firewall's request logs and the DNS queries for every public zone it serves to CloudWatch Logs; the firewall and DNS logs are kept 365 days. |
Application security and development
| # | Question | Answer | How it works |
|---|---|---|---|
| AS-1 | Are changes tested automatically before release? | Yes | Changes reach the main branches through pull requests that must pass one required check, covering the projects a change touches: type checks, linting, unit, integration and isolation tests, a database-drift check and container builds. Repository administrators can bypass the pull-request rule; a direct push to the development branch then fails a check afterwards. See Security overview. |
| AS-2 | Are build pipeline dependencies pinned? | Yes | Every third-party build action is pinned to an exact commit, and a check refuses workflow expressions written inside multi-line shell steps, so values reach those commands through environment variables. Container base images and the test database and cache are referenced by version tag, not a fixed digest. |
| AS-3 | Are container images scanned for vulnerabilities? | Per deployment | The AWS reference deployment's image registry scans every image when it is pushed. |
| AS-4 | How is injection prevented? | Yes | Database access uses parameterised queries. A saved query must be a single statement, and schema and permission statements are refused. Every run has a time limit, and it runs under a Fact Base role whenever the app endpoint, Agent grant or Flow step that runs it names one; the Builder gives the query endpoints it wires the reader role, and a query that changes data cannot be put on an endpoint without a role. |
| AS-5 | Do Agents' outbound requests avoid internal networks? | Yes | An Agent's HTTP calls refuse private, loopback and cloud-metadata addresses, checked again on every redirect. The same check covers a Flow's file fetches and business-application steps, and a Doc Base's website crawls. A Flow's HTTP request step calls the address its author configures without that check, including when an Agent runs that Flow. |
| AS-6 | Do error messages expose internal details? | No | Most unexpected errors in the Studio API return a generic message and a request id, with the detail only in the logs; the gateway that serves apps returns a generic message without a request id. A few paths return the underlying error's own message instead: creating a Solution, running a saved query in the Studio, and, from an app, a data query or starting a Flow. |
| AS-7 | Are uploads restricted? | Yes | Size limits, per-store type rules and quotas apply; anything a browser could run is served as a plain download. |
| AS-8 | Is the API documented? | Yes | The Studio API publishes a generated OpenAPI description. See APIs and integrations. |
Infrastructure and resilience
| # | Question | Answer | How it works |
|---|---|---|---|
| IR-1 | Where is the service hosted? | Per deployment | Flexday SaaS is defined in AWS US East (N. Virginia); a dedicated deployment runs in the region you choose. |
| IR-2 | Is data backed up? | Yes | Database backups are kept 7 days, or 30 in production, with a final snapshot before deletion; stored objects keep earlier versions for 30 days; the file system is backed up. See Reliability and business continuity. |
| IR-3 | Is the service redundant across availability zones? | Per deployment | The network spans two availability zones, with a NAT gateway in each in production, and most services run one to three copies. As configured, the database has one instance and the cache one node; a second of each is a setting. |
| IR-4 | Does work survive a failure? | Yes | Long work runs as durable jobs with heartbeats; builds and Agent turns resume from their record of finished steps; outside effects carry idempotency keys. |
| IR-5 | Can a failed release be rolled back? | Yes | A service whose new copies do not become healthy is rolled back to its previous version automatically. Database changes are forward-only. |
| IR-6 | Is there a web application firewall? | Per deployment | AWS WAF with managed rule sets in the AWS reference deployment, with some body-inspection rules set to count rather than block; in the Azure one, a Front Door WAF policy that limits the request rate per address and has no managed rule sets. |
| IR-7 | Are health checks used? | Yes | The load balancer sends traffic only to copies that pass their health check. The Studio API's check is a readiness check (the database is reachable, the schema is current and the copy is not shutting down); the gateway's and the web applications' checks confirm the process answers. |
AI and model providers
| # | Question | Answer | How it works |
|---|---|---|---|
| AI-1 | Which AI model providers are used? | Per deployment | Anthropic for Claude models, and Azure AI Foundry for GPT models and embeddings where a deployment is configured for them; OpenAI or Voyage AI can supply embeddings only, where a deployment is configured for them. See AI models. |
| AI-2 | Can we choose the model? | Configurable | Workspace owners and admins choose a model per use case on the AI models page, and an Agent can name its own; those settings offer only Claude models for the Builder. |
| AI-3 | Is it documented what is sent to the model provider? | Yes | See What reaches an AI model provider. |
| AI-4 | Can an AI assistant's actions be limited? | Yes | An Agent uses only the tools it is explicitly granted, inside its own Solution, under per-turn budgets. See Responsible AI. |
| AI-5 | Can AI behaviour be tested before release? | Configurable | Evaluation sets run against the real engine, and an Agent can be set to require a passing run before each publish. |
| AI-6 | Are there guardrails against misuse? | Configurable | Rate and length limits, blocked patterns, personal-data handling, blocked topics and optional moderation run before the model; they are set per Agent. |
| AI-7 | How is prompt injection handled? | Yes | Retrieved content and tool results are marked as untrusted, and the grant list, not the prompt, limits what an Agent can do. |
| AI-8 | Are answers traceable to sources? | Yes | An answer lists the retrieved documents its wording matches, decided by code rather than the model. |
| AI-9 | Is AI usage and cost visible? | Yes | Every completed model call is recorded by Solution and resource, and the Usage pages show its estimated cost. |
| AI-10 | Can the AI make changes without a person? | Yes | Within a conversation an Agent uses its granted tools on its own. The Builder works only when a person asks it to in chat, and while it works it can publish the Agents and Flows it builds, run a Flow to test it, and change the data, saved queries, gateway endpoints and sign-in settings that a live app already uses. A Flow starts by itself (on a schedule, an event, a webhook or a sign-in) only after a person switches it on, and an app's own files go live by themselves only after its first build; after that a person deploys them. |
Privacy
| # | Question | Answer | How it works |
|---|---|---|---|
| PR-1 | Is the personal data the platform holds documented? | Yes | Account data from your identity provider, plus whatever your Solutions contain, each with where it lives and how long it is kept. See the data inventory. |
| PR-2 | Is data replicated to another region? | No | The infrastructure code defines no copy of any store to another region. |
| PR-3 | Can data be deleted on request? | Yes | Rows, documents, files and whole Solutions can be deleted, and an offboarded workspace is purged after its retention window. There is no single function that erases one person's data across a workspace. |
| PR-4 | How long is data kept? | Configurable | Until you delete it, except for File Store retention windows you set, form submissions (removed after the workspace's retention window, 30 days by default) and short-lived records. |
| PR-5 | Can we export our data? | Yes | A Solution exports to one bundle file, with the data you choose; an offboarded workspace gets a final export. See Portability and exit. |
| PR-6 | Can personal data be masked in AI conversations? | Configurable | An Agent's personal-data guardrail can warn, mask or block card numbers, US social security numbers, email addresses and US-format phone numbers; it is off until switched on. |
| PR-7 | Are form answers stored separately? | Configurable | Only when storage is switched on for the form. Opening or listing stored answers is logged, and a Solution export that includes history also carries them. |
Operations and support
| # | Question | Answer | How it works |
|---|---|---|---|
| OS-1 | How are staff permissions controlled? | Yes | Staff hold one of three roles (super, support, read-only) in the Admin Console, checked on the server; no one can change their own role, and the last super administrator cannot be removed. |
| OS-2 | Can support staff act without our consent? | Yes | Support sessions need the support-access setting. Outside a session, staff with the support role can change a workspace's plan and quotas, suspend, offboard or restore it, start an export of it, reset its owner and change its sign-in setup, and those actions are recorded against them; a super administrator can also purge an offboarded workspace before its retention window ends. |
| OS-3 | Can we revoke Flexday's access? | Yes | An owner can switch off support access at any time; new sessions are refused and live ones end at their next request. |
| OS-4 | How are platform releases applied? | Per deployment | On AWS, database changes run first under a lock, then each changed service rolls with automatic rollback. In a dedicated deployment, whoever operates it decides when a release is applied. |
| OS-5 | Can we keep using our data if we leave? | Yes | Exports are zip files in open formats: each Fact Base's structure and rows as JSON, apps as their plain HTML, CSS and JavaScript files, and Flows, Agents and other definitions as JSON. See Portability and exit. |
Documents to request
These are facts about Flexday as a company, not about the platform, so this documentation does not state them. Ask Flexday for each one during due diligence.
| Topic | What to request |
|---|---|
| Attestations | Current third-party attestation reports or certificates, if any (for example SOC 2 or ISO/IEC 27001), with their scope and period |
| Security testing | The summary of the most recent independent penetration test, and the status of its findings |
| Vulnerability management | How dependencies are scanned for known vulnerabilities (the repository's pipeline defines no such scan; images are scanned when pushed, AS-3), and the time allowed to fix a vulnerability by severity |
| Secure development | The secure development policy, including code review and approval rules |
| Policies and people | The information security policy set, staff screening, security training and reviews of staff access |
| Key management | Who holds the platform's master key and the cloud keys, and how often each is rotated (the infrastructure code switches on automatic rotation only for the key it keeps ready for Secrets Manager) |
| Incident response | The incident response plan, and how and when customers are told about an incident or breach |
| Service levels | The availability commitment and how it is measured, support hours and response targets, and maintenance windows |
| Continuity | The business continuity and disaster recovery plans, the recovery objectives Flexday commits to, and the last restore test |
| Data processing | The data processing agreement, the sub-processor list with locations, and the mechanism for international transfers |
| AI providers | Each model provider's terms: whether it keeps or trains on your data, and where it processes requests |
| Hosting | The regions in which Flexday can host your workspace or a dedicated deployment |
| Commercial | Pricing, contract terms, liability, insurance cover and exit assistance |
| References | Customer references comparable to your organisation |