How MapFlow Protects Your Data
This statement describes MapFlow's security architecture and the controls that are in force by default — not the opt-in toggles that weaken the posture. MapFlow's posture is: the Local Proxy reaches the source database inside the council's own network (outbound-only); cipher data is written to a UK Sovereign Postgresstaging layer (PII is AES-256-GCM encrypted on the Local Proxy before it reaches staging, so the staging database only ever holds ciphertext); AI runs through the Local Proxy to a sovereign LLM (the Sovereign Inference Shuttle — the plaintext prompt and the LLM key never transit the Base44 backend); and the Base44 platform operates as the UI / orchestration layer only — it never holds plaintext PII, the PII encryption key, or any LLM API key. It is intended to support procurement and information-security reviews.
Last reviewed: 31 August 2026. MapFlow is hosted natively within pre-accredited, enterprise-grade Infrastructure and PaaS environments — the underlying Base44 application platform holds independent SOC 2 Type II, ISO/IEC 27001, and GDPR certifications and is hosted explicitly in the United Kingdom (UK). The UK Sovereign Postgres staging layer holds ciphertext PII only; the AES-256-GCM key never leaves the operator's Local Proxy (DPAPI-held), so the staging operator cannot be compelled to disclose plaintext it does not hold. This gives MapFlow a consistent end-to-end UK data-residency posture by default. The application-layer controls below are implemented and internally assured; see "Alignment & Caveats" at the foot of this page.
Architecture at a Glance
Ciphertext-Transit Posture. The Base44 application backend (US-parent-owned) operates exclusively as the UI and orchestration layer. Every PII value is AES-256-GCM encrypted on the operator's Local Proxy (DPAPI-held key) before it reaches Base44 or the UK Sovereign Postgres staging layer, and is decrypted only on the operator's Local Proxy. The platform therefore never holds exploitable plaintext — a US CLOUD Act production order against the US parent returns ciphertext and non-PII metadata only. The UK Sovereign Postgres and the UK-sovereign LLM providers are UK-registered, UK-owned, with no US operations, so under the UK Companies Act 2006 / UK GDPR they are bound only by UK domestic law — a US court warrant holds no legal authority over them, so the US CLOUD Act cannot, on its own, seize a copy of data held only by these UK-only entities. When AI is enabled, prompts are assembled and the UK-sovereign provider is called from the Local Proxy via the Sovereign Inference Shuttle (Prepare → Proxy → Finalize), so no plaintext prompt or LLM API key ever transits the US-parent platform.
MapFlow is a cloud-native web application. The frontend is a React single-page app hosted on the Base44 platform; Base44 operates as the UI / orchestration layer only — it never holds plaintext PII, the PII encryption key, or any LLM API key. The serverless backend orchestrates the flows (dispatching copy/load jobs, resolving Salesforce tokens, directing batches); PII encryption/decryption and LLM inference run on the operator's Local Proxy. No secrets, database credentials, or encryption keys are delivered to the browser. MapFlow handles three distinct flows that must not be conflated — structured data, documents, and AI — each with its own path:
Note on document sourcing: in the overwhelming majority of engagements (effectively all secure setups) source documents live on the council's own secure local filestore and are read by the Local Proxy from inside that network. If a client has chosen to store source files elsewhere (a public cloud, a third-party repository), that is a risk the client has already introduced to its own environment and is outside MapFlow's data path and responsibility.
Structured Data Flow — Source to Local Proxy (encrypt) to UK Sovereign Postgres (ciphertext) to Salesforce
1 · Source
Legacy database (SQL Server, Oracle, Postgres, MS Access) inside the council's secure network. Read-only; MapFlow never writes back to the source.
2 · Local Proxy
Outbound-only secure tunnel inside the council network. AES-256-GCM encrypts flagged PII with the DPAPI-held key. Streams ciphertext to the UK Sovereign Postgres over HTTPS/TLS 1.3. No inbound firewall ports are opened.
3 · UK Sovereign Postgres (ciphertext)
Managed Postgres staging, UK-hosted. Heavy joins and transformations run here, isolated per project, with RLS. Flagged PII fields are ciphertext only — the staging database and its operator never hold the plaintext or the key.
4 · Salesforce
Structured records loaded via MapFlow's serverless loader functions, which read ciphertext from staging, decrypt on the Local Proxy where required, and push to Salesforce over TLS 1.3.
Document Flow — Local Proxy (reads + compresses in-network) to Base44 backend (orchestration, server-side) to Salesforce ContentVersion
1 · Local Proxy (in-network)
The Local Proxy runs inside the council's secure network, reads source documents (PDFs, images) from the local filestore, and compresses them (pdfsizeopt, jpegoptim, optipng) in memory. The bytes never leave the council perimeter at this stage — no staging database, no third-party staging, no browser upload.
2 · Base44 backend (orchestration)
MapFlow's Base44 serverless backend is the orchestration middle hop: it holds the Salesforce credentials, resolves the Salesforce token server-side, and directs each batch. The Salesforce connection is the backend's responsibility — NOT configured on the proxy and never reaches the browser. The backend never holds document bytes at rest.
3 · Salesforce ContentVersion
The proxy streams the compressed bytes to Salesforce ContentVersion over its outbound-only TLS 1.3 tunnel, using the token the backend resolved. Salesforce is the final destination. Documents never touch the UK Sovereign Postgres — it is used only for encrypted structured-data staging.
AI Flow — Sovereign Inference Shuttle (when AI is enabled): Browser (ciphertext) to Local Proxy (decrypt + call) to UK Sovereign LLM
1 · Browser (ciphertext)
The browser POSTs ciphertext (ENC:-prefixed values) plus non-PII metadata plus a prompt template to the Local Proxy /llm-invoke route. The plaintext PII and the prompt never enter the Base44 backend.
2 · Local Proxy (decrypt + call)
The Local Proxy decrypts the ENC: values in volatile RAM with the DPAPI-held key, fills the template, and calls the UK-sovereign LLM using an API key held in the proxy's own environment. The plaintext prompt and the LLM key never transit Base44.
3 · UK Sovereign LLM
Inference runs on a UK-domiciled provider — Civo Project Mercury (LON1-pinned), relaxAI (Civo, UK data centres), or local Ollama (self-hosted). The response returns to the proxy and is finalised back to the browser. Stateless; nothing is persisted.
The Local Proxy — one outbound-only tunnel, three flows
The Local Proxy is a lightweight process running inside the council's own network. It solves the classic hybrid-cloud problem — how a cloud-native app talks to a legacy internal database without opening dangerous inbound ports — and it serves all three MapFlow flows: it tunnels ciphertext structured data out to the encrypted UK Sovereign Postgres staging layer, it compresses documents locally before streaming them straight to Salesforce, and it decrypts PII and calls the UK-sovereign LLM for the AI features. The PII encryption key (DPAPI-held) and the LLM provider key (proxy env) both live on the proxy, never on the US-parent Base44 platform. Where large corporate vendors demand public-facing ports or expensive site-to-site IPsec VPNs, MapFlow's tunnel is strictly outbound — so InfoSec only needs to audit a single well-defined traffic path.
Outbound-only traffic
The tunnel initiates encrypted connections out — to the UK Sovereign Postgres for data, to Salesforce for documents, to the UK LLM for AI — over standard HTTPS/TLS 1.3 ports.
No inbound ports needed
The council's network team opens zero inbound firewall rules; no external service can scan or directly ping the legacy database or the proxy.
Base44 never holds plaintext
PII is encrypted on the Local Proxy before it reaches Base44 or staging; the PII key and the LLM key live on the proxy (DPAPI-held / proxy env). A CLOUD Act order against the US-parent platform returns ciphertext and non-PII metadata only.
General Security Controls
The platform-wide controls that apply to all data MapFlow processes.
Identity & Authentication
- Email/password authentication with optional Google OAuth (OIDC).
- TOTP-based multi-factor authentication, admin-enforced per user, with 24-hour lockout policy and backup codes. Aligns to NIST SP 800-63B AAL2.
- Automatic inactivity session timeout (configurable 10 min to 2 hr) tracking mouse, keyboard, scroll, and touch activity.
- Password reset via time-limited single-use tokens; reset emails never reveal whether an address is registered.
Access Control & Row-Level Security
- Role-based access control (admin, user, specialist roles such as sql_utils).
- Row-Level Security on every entity — users only see records for projects they belong to; cross-tenant isolation is enforced at the database layer, not the UI.
- Tenancy boundary is the single Base44 tenant (app instance), enforced by database-layer RLS — INTRA-tenant object-level authorization is the security boundary MapFlow relies on. A 'Multi-Project' workspace (several council engagements grouped inside one tenant) is a client / System-Integrator convenience, NOT a security tenancy boundary: Project membership governs which records a user can see within the tenant (object-level access scoping), but the tenant itself is the isolation unit. Grouping engagements does not create, weaken, or replace the database-enforced cross-tenant boundary.
- Project membership governs read, create, update, and delete independently; ownership is required for destructive operations.
- Only admins may invite users, manage licences, or change security settings.
Secrets & Key Management (Local-Estate)
- PII encryption keys are held on the operator's Local Proxy under Windows DPAPI (or a parameter key) — never in the Base44 backend, never in a browser, never in a password manager. The Base44 platform never receives the raw key. Operators may optionally bind the key to the physical Trusted Platform Module (TPM 2.0) on the proxy host by enabling Windows Credential Guard, which moves the DPAPI master key into TPM-protected virtualisation-based-security memory — the key is then cryptographically bound to that specific hardware and cannot be unsealed on any other machine (see the TPM Key Binding Guide).
- LLM provider API keys (Civo Project Mercury, relaxAI, local Ollama) live in the Local Proxy's own environment — never as Base44 app secrets — so the sovereign inference call is authenticated entirely off the US-parent platform.
- Salesforce client secrets and source-database credentials are Base44 platform secrets used server-side only for orchestration; generated proxy/tool scripts phone home at runtime to retrieve credentials and never embed them in the script file.
- Licence keys are time-bombed (<=30 days) and individually revocable by an admin.
Audit, Integrity & Recovery
- Append-only audit trail: every mapping change, sign-off, and admin action is recorded with author, timestamp, and reason.
- Per-access SIEM audit logging — every signed-in app access is logged once per browser session, capturing who (email, role), when, the client IP, and city-level geography resolved from it (city, region, ISO country, latitude/longitude) plus the owning Autonomous System Number and ISP/organisation (e.g. ASN 16509 = Amazon AWS) and VPN/datacenter/hosting and UK-boundary signals. Each access event is written to an admin-only AccessLog record AND mirrored as an immutable JSON object to the audit S3 bucket (one file per event, ingestible by Splunk / AWS Security Lake / any S3-reading SIEM), so a SIRO or auditor can reconstruct exactly who entered the platform, from where, and via which provider. Only the IP is sent to the free geolocation sub-processors; no other user data.
- Semantic versioning with restorable snapshots — any previous mapping state can be recovered.
- Encrypted cloud backups with a tested restore path (see Backup & Recovery).
- Admin email alerts on overnight job failures; Salesforce metadata (validation rules, triggers, flows) is always restored after a load, even on failure.
- Proactive Security Threat Register — a live, database-backed register of threats to the platform, each with a full remedial action log (identified → authorised → applied) and a per-threat audit trail of every reassessment. An event-driven sweep fires immediately on every app publish (code push / deploy, new endpoints, dependency changes) so a newly-exposed endpoint or credential is scanned without waiting for the weekly cadence; the weekly AI web-search sweep is a structural / deep review (attack-surface mapping, brand protection, compliance benchmarking) that discovers new externally-corroborated threats and emails admins. Residual risks and their remediation status are surfaced to InfoSec continuously, not just at periodic review.
Data Protection by Design
- All free-text fields are encrypted by default — every text/varchar column is AES-256-GCM encrypted on the operator's Local Proxy (DPAPI-held key) before it reaches the UK Sovereign Postgres staging layer or the Base44 backend. The 'Encrypt all free-text' model is the default PII posture, so the staging database and Base44 only ever hold ciphertext for free-text fields — no AI scan of row data is required. Supports GDPR Article 25.
- Application-level encryption (AES-256-GCM) is performed on the Local Proxy (DPAPI-held key); the staging Postgres and the Base44 backend never hold plaintext for any free-text field.
- Parameterised database queries and server-side input validation mitigate injection risks (OWASP).
- No advertising or marketing-tracking scripts; analytics events are operational and carry no PII.
- Support-ticket and connector-onboarding conversations purge credentials automatically when closed.
Base44 — Application Platform
Hosting, database & browser storage
Purpose
MapFlow is built on the Base44 platform-as-a-service. In MapFlow's posture Base44 operates exclusively as the UI and orchestration layer: it hosts the React application, the managed database of app metadata (mapping configs, schema catalogues, DB connections, risk logs, support tickets, licence records, version history, audit trail), authentication, the serverless backend that orchestrates the flows, file storage for non-PII artefacts (screenshots, reports), and secrets management for orchestration credentials (Salesforce client secrets, source-database credentials). Base44 never holds plaintext PII, ciphertext PII, the PII encryption key, or any LLM API key. PII (plaintext or ciphertext) is never persisted to Base44's managed database or file storage — ciphertext PII at rest lives only in the UK Sovereign Postgres staging layer; Base44 only ever carries ciphertext in volatile memory in transit while orchestrating a read or write. The PII encryption key and the LLM API keys live on the operator's Local Proxy. This section details what Base44 stores on MapFlow's behalf, what the browser holds, and how it is protected.
What Base44 stores
- Application database — app metadata only (mapping configs, schema catalogues, DB connections, risk logs, support tickets, licence records, version history, audit trail) lives in Base44's managed MongoDB, gated by Row-Level Security enforced at the database layer; no app user can read another tenant's records. No citizen PII — plaintext or ciphertext — is ever persisted here. Ciphertext PII at rest lives only in the UK Sovereign Postgres staging layer; Base44's managed database never holds a single ciphertext PII value.
- User accounts & authentication — email/password and OAuth identities, role assignments, and MFA enrolment are stored and verified by Base44's managed auth. Passwords are hashed; session tokens are short-lived JWTs.
- Secrets management — Salesforce client secrets and source-database credentials used for orchestration are Base44 platform secrets, read server-side only and never delivered to the browser or client downloads. The PII encryption key and LLM provider keys are NOT Base44 secrets — they live on the Local Proxy.
- File storage — non-PII uploaded files (screenshots, session data, reports) are held in Base44's managed object storage and referenced by URL; private files are served via time-limited signed URLs. Citizen documents never touch Base44 storage — they are compressed on the Local Proxy and streamed straight to Salesforce.
- Backend runtime — the serverless backend orchestrates the flows (dispatching copy/load jobs, resolving Salesforce tokens, directing batches) but never performs PII encryption/decryption or LLM calls, and never persists ciphertext PII. In the sovereign posture, encryption/decryption and LLM inference run on the Local Proxy; Base44 only carries ciphertext and non-PII metadata in volatile memory in transit — ciphertext is streamed through the backend to its destination (the UK Sovereign Postgres or Salesforce) and is never written to Base44's managed database or file storage. During backup generation the ciphertext payload is built in volatile RAM and streamed straight to the connected cloud storage (Google Drive / OneDrive); it is never persisted in Base44.
- Audit trail — every create, update, and delete is recorded with author and timestamp by the platform; the append-only audit log is retained indefinitely.
What the browser stores
- Authentication token (JWT) in local storage to maintain the session; cleared on logout.
- Theme preference (light/dark), stored locally.
- Active project selection, held in memory for the session (not persisted to disk).
- Query cache — fetched app metadata held in memory only for the session; nothing sensitive is written to persistent browser storage.
Data residency
Base44 Inc. is a company that operates under United States jurisdiction, with its platform-as-a-service (PaaS) / orchestration engineering based in Oregon, USA. Base44's corporate origin and core development are Israel-based — the company was founded in Israel and its engineering is Israeli, while its commercial operations and PaaS orchestration run under US jurisdiction (Oregon). This is stated plainly so the US CLOUD Act exposure on the orchestration layer is addressed directly rather than obscured: Base44 is a US-jurisdiction entity, and a US production order can lawfully reach it. However, MapFlow's application metadata — the managed MongoDB, authentication, serverless runtime, file storage, and orchestration secrets held on MapFlow's behalf — is hosted explicitly in the United Kingdom (UK data centres), encrypted in transit (TLS) and at rest. Critically, ALL citizen data is blind to Base44: Base44 never holds plaintext or ciphertext citizen PII, the PII encryption key, or any LLM API key. Citizen data is controlled exclusively by MapFlow and resides only on UK Sovereign infrastructure (the UK Sovereign Postgres staging layer, ciphertext only) or the Local estate (the operator's Local Proxy, where the key is DPAPI/TPM-bound) — in AES-256-GCM encrypted form in both cases. Base44 only ever carries ciphertext in volatile memory in transit while orchestrating a read or write, and never persists it. A US CLOUD Act production order against Base44 (Oregon) therefore reaches app metadata only; it cannot reach citizen data, because Base44 never holds it. No data is shared with advertising or analytics third parties; operational analytics events carry no PII. This jurisdictional split — US-jurisdiction orchestration (Oregon) with UK-resident app metadata and UK-Sovereign / Local-estate citizen data — gives MapFlow a consistent end-to-end posture that addresses UK public-sector and GDPR data-residency requirements without reliance on EU or other-region hosting.
Platform Certifications — Base44 (Independently Audited)
SOC 2 Type II · ISO 27001 · GDPR DPA · 24/7 SOC monitoring — scope: the platform, not citizen data
Purpose
The Base44 platform that hosts and orchestrates MapFlow is independently certified and actively monitored. This is distinct from MapFlow's own application-layer controls (RLS, MFA, PII scanning, ciphertext-transit) which are implemented and internally assured but have not yet undergone a standalone audit of the application itself. The certifications below cover the platform layer — app-metadata hosting, user-account authentication, workspace/connector security, secrets management, and the build/deploy pipeline. Critically, citizen data never touches the Base44 backend and is never persisted there: ciphertext transits volatile RAM only during active pipelines and is never written to Base44 storage. The certification scope therefore covers the citizen-data-inert hosting layer the platform actually performs, not citizen-data processing.
Certifications & active monitoring
Independent audit of the design and operating effectiveness of Base44's security controls. Report available from the platform provider on request.
Certified Information Security Management System — the international standard. Certificate: https://www.wix.com/wix-platform/b44-security-trust/_files/ugd/dea07e_2c0242efe31a4434b31e675dd02b7eea.pdf
EU data-protection standards, with a Data Processing Agreement available on request from the platform provider.
Round-the-clock Security Operations Center powered by SIEM technology, supported by a dedicated security team.
Internal teams and third-party firms test defenses against real-world attack scenarios based on OWASP methodologies; every finding tracked to resolution.
Independent security researchers responsibly disclose vulnerabilities; the security team reviews, prioritises by severity, and fixes confirmed issues.
App data encrypted in transit (TLS 1.2+) and at rest (AES-256); secrets managed in a cloud key management service. Encryption covers backups.
Defined Recovery Time and Recovery Point Objectives aligned to industry standards, backed by frequent automated backups and documented recovery procedures.
Scope — what is and isn't covered
- Scope clarification (critical for the council file): the platform certifications cover the PLATFORM — app-metadata hosting, user-account auth, workspace/connector security, secrets management, and the build/deploy pipeline. Citizen data NEVER touches the Base44 backend and is NEVER persisted there: ciphertext transits volatile RAM only during active pipelines and is never written to Base44 storage; persistent ciphertext lives exclusively in the UK-sovereign Postgres. A US CLOUD Act production order against Base44 therefore returns app metadata only.
- Browser non-persistence & decrypt-on-request: citizen data is never persisted in the browser. PGLite (the in-browser staging DB) holds only transient rows for the active pipeline run and is dropped immediately on completion or on the auto-dispose step; IndexedDB holds app-state metadata only (project list, UI prefs) — never citizen PII. Decrypted values are surfaced to a signed-in, MFA-verified operator only on explicit request (a row-open / export action), never cached, and every decryption is written to the off-platform SIEM mirror (DataAccessAuditLog) with operator, timestamp, table, and justification — so the platform certifications cover the citizen-data-inert hosting layer while the decrypt-on-request window is itself evidence-chained.
- Client-owned certification scope: in a local-estate-only deployment, the following components are OUTSIDE Base44's boundary and are the CLIENT's responsibility to certify — (1) the Local Proxy host, (2) the locally-hosted LLM (Ollama / RelaxAI UK node), (3) the client-side Source Database, and (4) the UK-sovereign Postgres backend and its TPM-bound master key custody. MapFlow provides the cryptographic architecture (AES-256-GCM, blind indexes, TPM binding, MFA, RBAC, SIEM mirror) for these components but does not own the underlying estate.
- The 'Accredited Platform' argument on the MapFlow comparison page is evidence-backed against https://base44.com/security — SOC 2 Type II + ISO 27001 + GDPR DPA + 24/7 SOC monitoring. The platform certification is sufficient for the citizen-data-inert hosting layer it actually performs; the citizen-data-processing layer is sovereign by architecture and client-certified by estate.
Evidence & source
Source of truth: https://base44.com/security (retrieved 2026-08-27). The certifications and monitoring programme are maintained and attested by the platform provider (Base44 / Wix). Current attestation documents (SOC 2 Type II report, ISO 27001 certificate, GDPR DPA) are available from the platform provider on request. MapFlow surfaces them here so buyers can see the platform is independently certified, while being explicit that the certification scope is the platform layer — not the citizen-data-processing layer, which is sovereign by architecture.
This card records what the PLATFORM is certified for. It does not assert that MapFlow's own application-layer controls (RLS, MFA, PII scanning, ciphertext-transit, the Sovereign Inference Shuttle) carry the same badges — those are implemented and internally assured (see Security Testing & Assurance) and are the client's to certify in a local-estate deployment. Stating the platform's certifications plainly, without conflating them with the application's, is what lets a council assign liability accurately.
UK Sovereign Postgres — Encrypted Staging Layer
Ciphertext-only PII; key never leaves the Local Proxy
Purpose
Citizen data is staged in a UK-sovereign managed Postgres database. The staging layer is used for heavy joins, transformations, and reconciliation so the production source database is treated as read-only and never asked to perform expensive analytical work. Crucially, every PII value is AES-256-GCM encrypted on the operator's Local Proxy (DPAPI-held key) BEFORE it reaches the staging Postgres, so the staging database only ever holds ciphertext for flagged PII fields — the UK-hosted database operator never sees plaintext PII. Access is governed by a zero-trust credential model: a least-privilege Postgres role is provisioned server-side and the postgres superuser password is burned post-provisioning, so no human or application component retains superuser access to the staging database.
Security controls
- Per-project schema isolation — each client engagement gets its own database schema with RLS-enforced boundaries.
- RLS policies ensure app users can only access rows within projects they are a member of.
- Ciphertext-only PII — all free-text fields are encrypted with AES-256-GCM on the Local Proxy (DPAPI-held key) before being written to the staging Postgres, by default ('Encrypt all free-text'). The staging database and its operator never hold the plaintext or the key.
- Environment tiers (dev/test/live) within the staging database eliminate environment juggling and accidental cross-contamination.
- Managed UK Postgres scales horizontally — no 2 GB desktop ceiling — and CDC diff reports migrate only changed rows, not full tables.
- Connection credentials are platform secrets, never sent to the browser; generated copy scripts fetch them at runtime via authenticated phone-home.
- Zero-trust credential provisioning — after the UK Postgres project is provisioned, a least-privilege Postgres role is generated and installed server-side. The role name and password are produced with node:crypto inside an authenticated serverless function and never returned to the browser — not even to the admin who triggers provisioning — so no human can extract a usable database credential from the app.
- Least-privilege scope — the role has full DDL/DML on the project's own schemas (create/drop tables, views, sequences) but is explicitly denied access to platform internals (auth, storage, extensions, realtime). NOBYPASSRLS keeps row-level security intact.
- Encrypted credential at rest — the role's password is encrypted (AES-256-GCM, key derived from the app-held PII secret) before being written to the connection record; it is decrypted only server-side at connection time.
- Superuser burned post-provisioning — once the role is installed and verified, the postgres superuser password is rotated to a value nobody views or retains. After this step no human and no part of the application holds a superuser credential; the app only ever connects as the least-privilege role, eliminating the superuser password from the trust boundary entirely.
- Least-privilege enforced as a data-operation gate — every staging copy, load, sync, DDL, and read resolves its password through a single server-side helper that refuses to hand out the superuser credential. The superuser can therefore never be silently used for data movement — the role must exist before a single row moves.
- Schema copy jobs are split into lightweight dispatcher/worker tasks to avoid execution timeouts and ensure restartability.
Data residency
The UK Sovereign Postgres staging database is provisioned explicitly in the United Kingdom with a provider registered exclusively in the UK, owned by UK citizens, with no US operations. Under the UK Companies Act 2006 and the UK GDPR such a provider is legally bound only by UK domestic law — a US court warrant (including a CLOUD Act production order) holds no legal authority over an independent UK business, so the staging operator cannot be compelled by the US to disclose data it holds. This is the UK territorial-sovereignty position: the US CLOUD Act cannot, on its own, seize a copy of data held only by a UK-only entity. As a second, independent layer, every flagged PII value is AES-256-GCM encrypted on the operator's Local Proxy (DPAPI-held key) before it reaches the staging database, so even a lawful UK production order would return ciphertext only — the key never leaves the Local Proxy. The staging layer is therefore outside US CLOUD Act reach by jurisdiction and holds no plaintext PII by design. This gives MapFlow a consistent end-to-end UK data-residency posture for the staging layer. Client source databases remain on the client's own infrastructure and are read-only throughout.
Document Compression — Local Proxy Toolchain or ConvertAPI
Purpose, controls & data residency
Purpose
MapFlow reduces the size of PDF and image files before they are uploaded to Salesforce, eliminating the recurring per-GB Salesforce file-storage charge (the 'Salesforce Storage Tax') by ensuring only compressed documents land in ContentVersion. Documents are a separate flow from structured data: documents are compressed on the Local Proxy inside the council's own network and streamed straight to Salesforce — they never enter the UK Sovereign Postgres staging layer (used only for encrypted structured-data staging). The Local Proxy open-source toolchain is the default and InfoSec-recommended posture; ConvertAPI is available as a non-default alternative for engagements whose InfoSec has explicitly signed off a third-party sub-processor.
Security controls
- Local Proxy toolchain (default posture) — pdfsizeopt, Ghostscript, jpegoptim, and optipng run on the Local Proxy inside the council's own network, not on a workstation or a separate cloud hop. Documents are compressed locally and streamed straight to Salesforce.
- No third-party sub-processor in the default path — the open-source binaries run on the council's own proxy; no document byte is sent to a third-party cloud API in the default path.
- No data-residency question — documents stay inside the council network until the final compressed upload to Salesforce (the intended destination). No cross-border staging, no third-country processing.
- Outbound-only — the proxy initiates the encrypted upload to Salesforce over standard HTTPS/TLS 1.3; no inbound firewall ports are opened on the council perimeter.
- Corporate TLS-inspection trust (no verification bypass) — the Local Proxy and generated proxy scripts trust the council's own corporate CA bundle via the NODE_EXTRA_CA_CERTS / MAPFLOW_CA_BUNDLE / SSL_CERT_FILE environment variables. Certificate verification is never disabled (NODE_TLS_REJECT_UNAUTHORIZED is never set to 0), so licence validation and Salesforce uploads remain protected against Man-In-The-Middle interception even behind a corporate TLS-inspecting proxy.
- Documents bypass the staging Postgres entirely — the UK Sovereign Postgres is used only for encrypted structured-data staging; documents are compressed on the proxy and uploaded directly to ContentVersion.
- ConvertAPI is a non-default alternative — because it routes file bytes through a third-party cloud sub-processor, it requires an InfoSec review and sign-off before it may be enabled. Where InfoSec cannot approve a third-party sub-processor for document content, the Local Proxy toolchain (or compression_scope = 'none') is selected instead. Each client supplies its own ConvertAPI licence, stored per-project as a platform secret and used server-side only.
- In convertapi mode the original bytes are streamed in memory through ConvertAPI and the compressed result is uploaded directly; no file is persisted on ConvertAPI's servers. In local_proxy mode the bytes stay entirely within the council network.
- Compression can be scoped (Salesforce-only, or Salesforce + SharePoint) or disabled entirely (compression_scope = 'none') to preserve master-quality originals.
- Optional external archival — when compressing documents already in Salesforce (Storage Tax Reduction), the pre-compression original can be copied to a connected external store (SharePoint, Google Drive, or OneDrive) before the Salesforce version is retired, so the master is always kept. The external store is the client's own approved cloud tenant; the copy is made over the same outbound-only TLS 1.3 path.
- Closed-perimeter lockdown — for sensitive engagements (e.g. local-authority planning migrations containing enforcement notices, neighbour-dispute files, or financial evidence), the Local Proxy toolchain or compression_scope = 'none' is selected so no document ever leaves the council network until the compressed upload to Salesforce.
- A configurable minimum file-size threshold skips compression for files too small to benefit, avoiding unnecessary processing (Local Proxy) or API calls (convertapi).
- PDFs compress up to ~90% and images 70%+, with configurable quality presets (web, archive, lossless, text, ebook, printer). The Local Proxy toolchain additionally supports a lossless toggle for legal/master-quality documents that must not be re-encoded.
Data residency & retention
Local Proxy toolchain (default): open-source binaries run on the proxy inside the council's own network; documents are compressed locally and streamed straight to Salesforce over TLS 1.3 and never leave the council network until the final compressed upload. No third-party sub-processor is introduced, so there is no cross-border processing to assess and no data-residency question to answer — this is the InfoSec-recommended posture and the MapFlow default. ConvertAPI mode (non-default, requires InfoSec sign-off): per ConvertAPI's published terms the service processes data in-memory with zero persistence and operates EU-region endpoints, satisfying UK/EU data-residency and GDPR requirements; however, because it is a third-party sub-processor it must be explicitly reviewed and approved by InfoSec before use. For engagements whose InfoSec policy prohibits any third-party sub-processor for document content, the Local Proxy toolchain (or compression_scope = 'none') is selected and the data perimeter remains fully closed.
Document compression is a cost-optimisation feature, not a security control, and is entirely optional. The Local Proxy toolchain is the default and InfoSec-recommended path — no third-party sub-processor, no data-residency question. ConvertAPI is a non-default alternative that routes bytes through a third-party cloud API and requires an InfoSec review and sign-off before it may be enabled. Clients retain full control: compression is disabled by default and only active when an admin has explicitly enabled and configured it; for engagements requiring a completely closed data perimeter, MapFlow selects the Local Proxy toolchain or locks compression to 'none'.
Backup & Recovery — Encrypted, Same-App by Default
Encrypted backups, same-app restore, Master Recovery Key for cross-app
Purpose
MapFlow maintains encrypted cloud backups of all application data — mapping configurations, schema catalogues, DB connections (credentials redacted), audit trail, version history, and Document Audit partition rows — so a full engagement can be recovered after data loss or a platform incident. Backups are written to the project's connected cloud storage (Google Drive or OneDrive) on a schedule and on demand. CRITICAL CLARIFICATION — the ciphertext written to Google Drive / OneDrive is BASE44 APP METADATA ONLY, never citizen PII data. A backup contains mapping configs, schema catalogues, audit rows, and redacted DB-connection records — the operational metadata that makes the app work — encrypted with AES-256-GCM before it leaves the application. No citizen PII (plaintext or ciphertext) is ever written to Google Drive or OneDrive: citizen PII ciphertext lives only in the UK Sovereign Postgres staging layer, and citizen documents are compressed on the Local Proxy and streamed straight to Salesforce — neither ever touches the cloud-storage backup destination. Google Drive and OneDrive therefore hold an encrypted copy of the app's configuration and audit metadata, nothing more. By design, a backup is only restorable into the same Base44 application instance that created it; restoring into a different instance requires the Master Recovery Key, held as a Base44 platform secret (see Key Storage below).
Security controls
- Encrypted by default — every backup payload (Base44 app metadata: entity metadata and Document Audit partition rows) is encrypted with AES-256-GCM at upload time using the active PII key before it touches cloud storage. The provider therefore only ever holds encrypted app metadata; a compromised or subpoenaed Drive/OneDrive folder cannot leak readable mapping or audit data. Crucially, no citizen PII (plaintext or ciphertext) is ever written to Google Drive or OneDrive — the backup is app metadata only.
- Same-app restore by default — restoring into the originating app needs no key entry. The app resolves the PII key server-side from its own platform secrets and decrypts transparently. This is the normal recovery path and needs zero human key handling — nothing to lose, email, or misroute.
- Cross-app restore requires the Master Recovery Key — restoring into a different Base44 instance (DR to a fresh tenant, or migrating an engagement between environments) is deliberately gated. The destination app does not hold the originating app's PII key, so an admin must supply the Master Recovery Key via the Restore UI; without it cross-app decryption is refused. This prevents one app's backups from being silently imported into another.
- Council-held Master key = sovereign cross-app restore — when the Master (archive) key is created, a copy is provided to the Council so the Council retains it in its own approved secrets vault. Because the Council holds the raw key, any restore the Council performs is performed via the cross-app restore path (the Council supplies its vault-held key via the Restore UI), not the same-app auto-resolve path. This gives the Council sovereign, vendor-independent recovery: the Council can always restore its own backups directly without depending on VGT or the Base44 platform being available, and can revoke VGT's access at any time by rotating the role password in its own vault.
- Key storage — the Master Recovery Key is the PII encryption key, stored as a Base44 platform secret (or, optionally, the UK Sovereign Postgres Vault). It is never kept in a password manager (LastPass, Bitwarden, 1Password). Platform secrets are handled entirely server-side, encrypted at rest (AES-256-GCM), never delivered to the browser, and never transmitted to an external sub-processor. Keeping the key inside the already-approved, UK-resident architecture removes the password manager from the trust boundary entirely.
- Server-side only — all encryption and decryption for backup/restore runs inside authenticated serverless functions. The raw key is never returned to the browser, never logged, and never embedded in client downloads or generated scripts.
- Per-entity, restorable payloads — backups are written per entity (chunked for oversized Document Audit partitions), with a manifest of record counts and checksums so a restore can be verified against the source. Project IDs are remapped during cross-app restore so foreign keys resolve to the new target project.
- TPM-bound key option — operators may optionally bind the Local Proxy's AES-256-GCM session key to the physical TPM 2.0 chip on the proxy host by enabling Windows Credential Guard. Once enabled, the key is cryptographically bound to that specific motherboard and cannot be unsealed on any other machine, even if the disk is stolen or the VM is snapshotted. The proxy scripts (Python keyring / Node keytar) are unchanged — Credential Guard makes those calls TPM-backed transparently. See the TPM Key Binding Guide (/tpm-key-binding) for the provisioning and DR procedure.
- Master Recovery Key escrowed to IT — when the key is provisioned (standard DPAPI or TPM-bound), the raw base64 Master Recovery Key is exported exactly once and handed to IT / Governance to store in their own enterprise vault (Azure Key Vault, HashiCorp Vault, HSM, or a physical safe). This is the formal, auditable break-glass path: if the proxy hardware (and its TPM) is destroyed, IT retrieves the vault key and re-seals it onto a replacement host via the DR restore script, so all previously-encrypted ciphertext remains decryptable. The raw key never lives on the proxy host after provisioning and never reaches Base44.
- Tested restore path — the backup to restore path is exercised as part of internal assurance testing (see Security Testing & Assurance), confirming encrypted backups can be decrypted and that record counts match the manifest after restore.
- Retention — outdated backup folders are cleaned up automatically on a configured retention schedule; backups are not retained indefinitely, limiting the volume of recoverable ciphertext at rest.
Data residency & key storage
The ciphertext written to Google Drive / OneDrive is BASE44 APP METADATA ONLY — mapping configurations, schema catalogues, audit trail, version history, and redacted DB-connection records — never citizen PII. No citizen PII (plaintext or ciphertext) is ever written to the cloud-storage backup destination: citizen PII ciphertext lives only in the UK Sovereign Postgres staging layer, and citizen documents are compressed on the Local Proxy and streamed straight to Salesforce. The app-metadata backup is encrypted (AES-256-GCM) before it leaves the application, so the cloud storage provider (Google Drive or OneDrive) only ever holds encrypted app metadata. Because the plaintext never reaches the provider, the data-residency question for backups reduces to where the key is held — and the Master Recovery Key is held as a Base44 platform secret within the UK-resident application platform (or, optionally, the UK-resident Postgres Vault), both inside the already-approved UK hosting perimeter. No readable backup data is processed or stored outside the UK. The key never reaches a browser or an external sub-processor, and no password manager is in the data path.
Same-app restore needs no key handling at all; cross-app restore is gated on an admin supplying the Master Recovery Key, so recovery is simple in the normal case and firmly controlled across applications. The key is a Base44 platform secret — not a password manager — handled entirely server-side and never reaching a browser or external sub-processor, which removes LastPass (and any equivalent vault) from the backup-recovery trust boundary entirely. IMPORTANT: Google Drive and OneDrive hold ENCRYPTED BASE44 APP METADATA ONLY (mapping configs, schema catalogues, audit rows, redacted connection records) — never citizen PII. Citizen PII ciphertext lives only in the UK Sovereign Postgres; citizen documents go straight to Salesforce. The cloud-storage backup is not a data backup, it is a configuration/audit backup.
AI Processing — Sovereign Inference Shuttle
Disabled by default; when on, ciphertext through Base44, decrypt + UK LLM on the Local Proxy
Purpose
MapFlow offers two field-mapping engines: a non-AI reverse-engineering engine (the default) and an AI-assisted engine. The non-AI engine (reverseEngineerMappings) performs algorithmic matching using schema metadata — column names, types, profiler analysis, candidate record pairs, and stored learning — entirely within the Base44 UK server-side runtime, with zero data shared with any AI provider. The AI-assisted engine (aiSuggestFieldMapping) uses a large-language model to propose how source columns map to destination fields. MapFlow also uses AI for PII scanning, including the optional Deep PII scan. The output of PII scanning determines which fields are flagged for application-level encryption at rest (AES-256-GCM). By default AI is disabled (the master kill switch, llm_enabled = false, ships off) so MapFlow has zero external AI dependency out of the box; when an admin enables AI, all AI runs through the Sovereign Inference Shuttle (see below) — the plaintext prompt and the LLM key never transit the Base44 backend.
Providers
When AI is enabled, MapFlow routes inference to a UK-sovereign endpoint via the Local Proxy — not through a US-parent LLM. The supported sovereign providers are: Civo Project Mercury (LON1-pinned, Locai Labs + Civo), relaxAI (Civo, OpenAI-compatible at https://api.relax.ai, hosted in UK data centres with ISO 27001 / Cyber Essentials / SOC 2 and a default opt-out of training), and local Ollama (self-hosted on the operator's machine, reached via the Local Proxy). Local Ollama is a first-class option for engagements that require absolute data residency: Ollama runs as a Windows service on the operator's own laptop/desktop (models such as Llama-3, Phi-3, Mistral, Qwen 2.5), bound to 127.0.0.1:11434 so the model API is reachable only from the same machine as the proxy; the proxy decrypts ENC: cells in volatile RAM, forwards the prompt to the loopback-only Ollama, and returns only the model's textual answer. The runtime host can be fully air-gapped — models are pulled once on a separate jump host and then never reach the public internet during inference. The LLM provider API key lives in the Local Proxy's own environment — never as a Base44 app secret — and the plaintext prompt is assembled on the UK machine. The Sovereign Inference Shuttle (Prepare -> Proxy -> Finalize) means the browser POSTs ciphertext (ENC:-prefixed values) plus non-PII metadata plus a prompt template to the Local Proxy /llm-invoke route; the proxy decrypts the ENC: values in volatile RAM with the DPAPI-held key, fills the template, and calls the UK-domiciled LLM. Neither the plaintext prompt nor the LLM API key ever transits the US-parent Base44 backend. Per-feature model selection lets each AI feature (field mapping, screenshot vision detection, table profiling, PII classification, PL/SQL rules, conversational) use the model best suited to its workload. The master kill switch and the per-feature gates (Deep PII Scan, Follow-Me AI) apply regardless of which provider is selected.
Security controls
- AI disabled by default — the master kill switch (llm_enabled) ships OFF, so every InvokeLLM-dependent function short-circuits: analytical features run their deterministic non-AI replacements, and conversational/vision features return a clean 'AI disabled' state. MapFlow has zero external AI dependency out of the box.
- Sovereign Inference Shuttle (the posture when AI is on) — the browser sends ciphertext + non-PII metadata + a prompt template to the Local Proxy /llm-invoke route; the proxy decrypts ENC: values in volatile RAM, fills the template, and calls the UK-domiciled LLM. The plaintext prompt and the LLM API key never transit the Base44 backend. This is the genuine ciphertext-through-Base44 posture for sovereign AI.
- UK-sovereign providers only — when AI is enabled, inference is routed to Civo Project Mercury (LON1-pinned), relaxAI (Civo, UK data centres), or local Ollama. No US-parent LLM is in the AI data path. The provider key lives in the Local Proxy's environment, never in Base44 app secrets.
- Design-time only — AI is used during mapping analysis and PII scanning, never during the live data load. The record-transfer pipeline does not call AI services.
- Minimal data exposure — PII scanning sends column names, types, and (for Deep PII scan) a small sample of row values. Full tables are never transmitted.
- Stateless processing — prompts and responses are not persisted by MapFlow beyond an audit-trail record that an analysis was run on a given table; the providers process requests via stateless API calls.
- No model training on customer data — the sovereign providers' published terms prohibit training on customer data (relaxAI defaults to opt-out of training). Clients should review the relevant provider's DPA.
- All free-text fields are encrypted by default — 'Encrypt all free-text' adds every text/varchar column to the encryption set automatically, so all free-text PII is protected at rest (AES-256-GCM on the Local Proxy) without any AI scan of row data. This is the Infosec-preferred posture because no customer text leaves the closed perimeter for AI classification.
- Deep PII scan is admin-gated — standard PII scanning uses column metadata only; the deeper row-level Deep PII scan runs only when an admin explicitly enables it (deep_pii_scan_enabled, default off), and can be bypassed via the default 'Encrypt all free-text'.
- Non-AI field mapping is the default — the reverse-engineering engine performs algorithmic field matching using schema metadata entirely within the Base44 UK server-side runtime. Zero sample data, candidate record values, or any other citizen data is shared with any AI provider. This is the InfoSec-preferred posture for field mapping.
- Follow-Me AI is admin-gated — the AI-assisted field-mapping engine (Follow-Me) is disabled by default (follow_me_ai_enabled = false). When an admin explicitly enables it, the engine sends schema metadata and sample rows to the UK-sovereign LLM via the Sovereign Inference Shuttle. Enabling it surfaces an in-app InfoSec warning and is flagged in the weekly posture report. The non-AI engine remains available regardless.
- Per-feature model selection — each AI feature is matched to the sovereign model best suited to its workload (e.g. a vision model for screenshot detection, a reasoning model for field mapping), so each feature proactively uses the optimal UK-hosted model rather than a single shared model.
Data residency
AI is disabled by default (llm_enabled = false), so for the standard posture there is no AI data-residency question at all — no citizen data leaves the closed perimeter for AI processing. When an admin enables AI, all inference runs through the Sovereign Inference Shuttle: the plaintext prompt is assembled and the UK-sovereign LLM is called from the Local Proxy (Civo Project Mercury LON1, relaxAI, or local Ollama). The plaintext prompt and the LLM API key never transit the US-parent Base44 backend. The sovereign LLM providers are registered exclusively in the UK, owned by UK citizens, with no US operations (Civo and relaxAI are UK-domiciled; local Ollama is self-hosted on the operator's own machine). Under the UK Companies Act 2006 and the UK GDPR such providers are legally bound only by UK domestic law — a US CLOUD Act production order holds no legal authority over them, so they cannot be compelled by the US to disclose prompts or responses. Processing is stateless: no customer data is stored by the providers beyond the duration of the API request, per their published terms.
AI processing is a design-time analysis tool, not a runtime data-processing control — the AI never touches data during the actual migration. The standard posture is AI disabled (zero external AI dependency). When AI is enabled, the Sovereign Inference Shuttle keeps the plaintext prompt and the LLM key on the operator's Local Proxy and routes inference to a UK-sovereign provider, so the US-parent Base44 backend never sees plaintext prompts or LLM credentials. The default 'Encrypt all free-text' protects all free-text at rest on the Local Proxy without any AI scan, and the default field-mapping engine is non-AI (algorithmic). Note on DPAs: clients should review the relevant sovereign provider's published DPA for the selected model.
Security Testing & Assurance
Internal verification of every control claim
Purpose
MapFlow's controls are not just documented — they are actively tested. Internal assurance testing verifies that the controls described here actually hold under real conditions: that RLS isolates tenants, that MFA cannot be bypassed, that secrets never reach the browser, that PII is encrypted on the Local Proxy before it reaches the staging Postgres, and that the audit trail is tamper-evident. This is internal assurance, not third-party certification (see caveat below).
Internal assurance tests
- Tenant isolation — RLS boundary checks confirm no app user can read, create, update, or delete another tenant's records across every entity.
- Authentication & MFA — verification that unauthenticated requests are rejected, sessions expire on inactivity, and MFA-gated operations cannot proceed without a valid second factor.
- Secret exposure audits — static and runtime checks confirm API keys, database credentials, and encryption keys are never delivered to the browser or embedded in client downloads; PII keys and LLM keys are confirmed to live on the Local Proxy, not in Base44.
- Ciphertext-transit verification — checks confirm flagged PII values are AES-256-GCM encrypted on the Local Proxy before they reach the staging Postgres, and that the staging database holds ciphertext only.
- Audit-trail integrity — verification that mapping changes, sign-offs, and admin actions are recorded immutably with author identity and timestamp.
- Input validation & injection — parameterised-query verification and server-side validation checks against OWASP injection categories.
- Recovery — the backup to restore path is exercised to confirm data can be recovered; Salesforce metadata restoration is verified after every load, including on failure.
Test cadence
Internal assurance testing is performed on each material release and on any change touching authentication, Row-Level Security, secret handling, or the ciphertext-transit path. Findings are remediated before release; residual risks are recorded in the Risk Log.
Platform scanning (Base44)
In addition to MapFlow's own testing, the application runs on the Base44 platform, which performs security scanning and ongoing review of the managed infrastructure (managed database, authentication, serverless runtime, file storage, secrets) as part of its platform responsibilities. The authoritative detail of Base44's scanning programme — scope, cadence, and findings handling — is maintained by the platform provider and available from Base44 support on request. MapFlow depends on this platform-level assurance for the infrastructure it does not control, and complements it with the application-level testing above.
Proactive InfoSec Posture Monitoring
13 zero-trust checks + 5 IP/location signals, weekly + on demand, admin alerts on critical / high
Purpose
MapFlow continuously verifies that its controls hold in practice, not just on paper. A built-in InfoSec posture runner executes a suite of proactive zero-trust checks plus a group of five IP/location signal checks against the live configuration and records the result of every check. The runner is scheduled weekly (every Monday 09:00 Europe/London) and can be triggered on demand from the InfoSec Posture Check panel in the Admin Dashboard. Each run writes one auditable record per check, grouped by a shared run ID, so a complete history of posture over time is preserved. When any Critical or High violation is found the runner emails every administrator an alert with the offending checks and remediation guidance, so posture degradation is surfaced immediately rather than at the next periodic review. The IP/location signal group additionally runs on app load for every signed-in user (not just admins), enforcing the admin-configured per-signal policies with a dismissible warning banner (warn) or an app-layer access-denied gate (block); a per-user, per-signal 6-hour throttle prevents repeat logging and email on repeated page loads.
Severity tiers & checks
Back-door / superuser-class credential paths — a staging Postgres connection still on the postgres superuser, untrusted (non-localhost) proxy or non-Salesforce instance URLs (SSRF surface), and an admin IP on the FireHOL Level 3 attacker blocklist (block policy).
Weakened authentication or data-residency boundary — an admin without active MFA, AI residency enforcement switched off, the cloud-DB proxy kill switch turned off (direct cloud-DB connection permitted), unencrypted synced audit partitions holding rows, a running document job with no Salesforce API governor, and non-UK admin access or a VPN/datacenter IP detected under a warn/block policy.
Intended-but-risky control enabled — Deep PII Scan on, cloud sub-processor (ConvertAPI) compression on, a closed connector conversation with un-purged credentials, an expired decryption session still active, the InfoSec check itself stale (no run in >8 days), and a VPN/datacenter IP or browser-timezone mismatch under a warn policy.
Informational hygiene — Google Drive connected on a personal (free-provider) account, and an IP/location signal set to log-only (detected and recorded but admins are not emailed).
Schedule & auditing
Weekly (Mondays 09:00 Europe/London) via the scheduled InfoSec posture workflow, and on demand from Admin -> InfoSec Posture Check. Every run is stored against a unique run ID so the history of posture — and any remediation — is fully auditable; admins are emailed automatically whenever a Critical or High violation is detected.
IP / location signal policies
The IP/location check group resolves the requesting user's IP and evaluates five location/tunneling signals, each independently configurable with a per-signal policy of off (not evaluated), log (recorded as informational, no admin email), warn (violation + email every admin), or block (higher-severity violation flagged as a block + email every admin): non-UK IP (access from outside the UK boundary), VPN/datacenter IP (proxy, hosting/cloud, or mobile-VPN exit), timezone mismatch (UK IP but browser timezone is not Europe/London — the strongest tunneling signal), attacker blocklist (IP on the FireHOL Level 3 threat-intelligence feed), and outside Council IP ranges (the signed-in IP falls outside the admin-configured Council CIDR allow-list — the council's office ranges plus its known VPN exit IP — so any connection from beyond the Council network boundary is flagged). This group runs on app load for every signed-in user — not just admins — and enforces the admin-configured policies at the app layer: warn shows the flagged user a dismissible banner, block shows an access-denied screen so the user cannot use the application, and both email every administrator. A per-user, per-signal 6-hour throttle prevents repeat logging and email on repeated page loads. The platform owns the auth backend, so warn/block flags and email alerts rather than hard-login-boundary enforcement; only the IP is sent to the geolocation sub-processors, no other user data. Recommended Gold-Standard defaults ship out of the box: non-UK = warn, VPN/datacenter = block (admin tier), timezone = log, FireHOL = block, and Council IP allow-list = block when Council ranges are configured (opt-in). Admins and regular users have independent tiers. An admin may grant an individual user a relaxed IP/location check via a per-user exception, which is fully auditable and only relaxes the specific signals chosen. Exceptions are honoured only when the user's multi-factor authentication is active; if MFA is disabled, full security applies. In addition, MapFlow refuses automated AI / crawler User-Agents on any signed-in session via a server-side denylist and a robots.txt that disallows the same crawlers from public pages.
Disabling a check
Each fixed check can be individually disabled by an admin from the Posture Check configuration panel — useful only when a check is broken or noisy for the environment, since disabling a check removes its coverage and weakens zero-trust posture. A disabled check is skipped (logged as a single informational 'check disabled by admin' row; it never counts as a violation and never triggers an admin email), and the panel surfaces a live 'InfoSec posture weakened' warning that names every disabled check and every IP/location signal set to off or log-only, so the degradation is visible to the admin who caused it at the point of the change.
Proactive posture monitoring is assurance, not a substitute for the controls it checks. It detects when a control has been weakened (intentionally or accidentally) and surfaces it immediately to administrators — including the admin who loosened it, who sees an inline InfoSec impact warning at the point of the change — so posture degradation never goes unnoticed between reviews. The runner itself runs under the same zero-trust model: it executes as an authenticated serverless function, reads configuration via least-privilege SDK calls, and cannot alter any control.
Monthly Salesforce Re-authentication — Identity Re-verification
30-day window + 7-day grace; decryption auto-suspends across all staged PII paths
Purpose
MapFlow enforces a mandatory monthly Salesforce re-authentication (an identity re-verification / session-expiration policy) over every path that can decrypt encrypted PII held in a council's UK Sovereign Postgres staging warehouse. An administrator must complete a Salesforce login in the browser (the same OAuth flow Salesforce Data Loader uses) once a month for each council; the completed login (Salesforce user, organisation, timestamp) is recorded immutably per project. The login is valid for 30 days, followed by a 7-day grace period during which decryption still works and reminders are emailed to administrators weekly. Once the grace period ends, decryption is automatically suspended — all encrypted data in the staging Postgres stays encrypted and unreadable — until an administrator re-authenticates. Crucially, the gate applies to every decryption path: the in-app table viewer, document-audit row viewing, the AI Assistant via a DecryptionSession, and DecryptionSession provisioning itself — every path that can unencrypt staged PII. Read-only access to non-encrypted schemas and metadata remains available throughout, so the platform is never fully locked out — only the decryption of encrypted PII is suspended.
Security controls
- Browser OAuth re-authentication — the admin clicks 'Re-authenticate with Salesforce' in the admin re-authentication panel; Salesforce opens an OAuth login in the browser (the same flow Salesforce Data Loader uses) and the completed login (Salesforce username + org + timestamp) is recorded immutably per project. The Connected App's client secret never reaches the browser; only the authorisation code is exchanged server-side.
- 30-day window + 7-day grace — the re-auth is valid for 30 days. A weekly reminder workflow (Mondays 09:00 Europe/London) emails admins when a re-auth is approaching expiry, in its grace period, suspended, or never recorded, so lapse is never silent.
- Automatic decryption suspension — once the 30-day window and 7-day grace period both elapse, every server-side decryption path refuses to decrypt; encrypted PII in the staging Postgres remains ciphertext. Read-only metadata and non-encrypted access are unaffected.
- Universal scope — the gate is enforced at every decryption entry point (table viewer, document-audit row viewer, AI Assistant DecryptionSession use, and DecryptionSession provisioning) via a single shared server-side helper, so there is no path that can unencrypt staged PII while the re-auth is lapsed.
- Defence-in-depth with MFA — the re-auth complements, not replaces, the existing MFA-gated DecryptionSession model: decrypting PII requires (1) an admin MFA code to provision a short-lived session AND (2) a recent Salesforce browser re-authentication for the council, so a stolen session alone is not enough.
- Auditability — every completed re-auth is recorded with the Salesforce user, Salesforce organisation ID, MapFlow admin, and timestamp, so a SIRO or auditor can see exactly who re-verified identity and when.
Why it matters
For council SIROs and auditors this is proof of a true Zero-Trust environment: even if an external BI tool or a user's machine is compromised, the maximum exposure window for unencrypted data is strictly limited to ~30 days before the entire decryption pipeline automatically locks down.
In local government, staff change roles, contractors leave, and accounts are terminated frequently. A mandatory monthly login forces the system to re-check against the live Salesforce directory, automatically cutting off 'ghost users' whose credentials are no longer valid — a forgotten deactivation cannot leave a stale account with permanent access to unencrypted council reports.
The rule keeps MapFlow firmly positioned as the active, indispensable gatekeeper of the council's data: a client cannot build a one-time workaround script to extract all the data once and bypass the platform, because they must continuously route through MapFlow's authenticated architecture to keep decryption flowing.
This is an identity re-verification (session-expiration) control, not a substitute for MFA or encryption. It caps the blast radius of a compromised token or key and re-confirms live directory access monthly. The re-auth is per council project; a council with no encrypted staged data requires no re-auth. Note: an administrator who has already lawfully retrieved a raw encryption key (MFA-gated) could technically decrypt offline; the control governs the platform's decryption services, guaranteeing the app itself cannot unencrypt staged PII while the re-auth is lapsed.
No Vendor Lock-In — Script Builder Exit Strategy
Portable conversion logic the client runs without MapFlow
Security & portability controls
- Script Builder exports every mapping's source→destination conversion logic as a standalone Python or Node runner, or a plain .sql bundle, that the client can execute against the source database from the command line.
- The generated runner embeds the conversion SQL as base64 JSON and needs only the matching database driver (oracledb / pyodbc / psycopg2, or npm: oracledb / mssql / pg) — no MapFlow account, no API key, no runtime dependency on the platform.
- No vendor lock-in: a client can rebuild the destination views/tables entirely independently of MapFlow. The mapping logic leaves with the data — a documented exit strategy and a bus-factor safeguard.
- Supports --dry-run, --only, and --no-commit modes so a client can validate the handoff before applying it.
Genuinely portable, plain-standard-SQL conversion logic is a data-portability control (UK GDPR Article 20 — right to data portability). MapFlow does not lock client data or mapping logic into the platform; the Script Builder is the mechanism by which a client exercises that portability right at any time.
Standards MapFlow Aligns With
MapFlow aligns with these standards at the application layer; its hosting stack (Base44) is independently certified and the UK Sovereign Postgres staging layer holds ciphertext PII only — see caveat below.
Data Protection by Design — PII scanning at design time identifies fields for encryption at rest (AES-256-GCM on the Local Proxy), plus least-privilege RLS.
Records of processing — audit trail and version history document every data-handling action.
TOTP-based MFA meets Authenticator Assurance Level 2.
ISMS control families — RBAC, MFA, session timeout, audit logging, backup, key management.
AC-2 (Account Management), AU-6 (Audit Review), SC-8 (Transmission Confidentiality), CP-9 (Backup — AES-256-GCM encrypted, same-app default, Master Recovery Key for cross-app).
Authenticator management — least-privilege staging Postgres role generated server-side, postgres superuser password burned post-provisioning, no retained superuser credential, role password encrypted at rest (AES-256-GCM).
Session termination — front-end user sessions auto-terminate after a configurable inactivity timeout. Separately, the Salesforce connection that authorises decryption of staged PII is re-verified monthly: it auto-terminates after a 30-day validity window + 7-day grace, requiring a fresh Salesforce browser re-authentication to restore.
Asset protection, separation (multi-tenant RLS), secure user management.
Server-side validation, parameterised queries, no client-side secrets, authenticated backend functions.
Secure configuration, access control, malware protection, boundary firewalls, patch management.
Proactive Endpoint & Application Monitoring (Roboshadow)
Continuous vulnerability scanning, patch tracking, and remediation across the operator estate and the MapFlow application
Purpose
Roboshadow provides proactive cyber security monitoring of operator endpoints (laptops, desktops) and the MapFlow web application. It continuously scans for vulnerabilities (CVEs), tracks patch status, and manages remediation — so security weaknesses are detected and fixed before they can be exploited, not after an incident. This is distinct from the weekly InfoSec posture runner (which checks the app's own configuration): Roboshadow monitors the estate the app runs on and the application's external posture.
Security controls
- Continuous endpoint vulnerability scanning — Roboshadow scans every operator laptop and desktop for known vulnerabilities (CVEs), misconfigurations, missing patches, and weak security settings, flagging issues before they are exploited.
- Application-layer monitoring — the MapFlow web application itself is monitored for security posture changes, exposed endpoints, and configuration drift, complementing the weekly internal InfoSec posture runner.
- Patch management tracking — missing OS and application patches are tracked to resolution, with SLA-based prioritisation by severity.
- Remediation workflow — every finding is assigned, tracked, and closed; no finding is silently dismissed.
- Three-tier separation — Roboshadow (endpoint & app monitoring) is distinct from Base44 (platform infrastructure, SOC 2 / ISO 27001) and VGT/MapFlow (app-layer code). A finding is routed to the correct owner for remediation: endpoint vulnerabilities to Roboshadow, platform issues to Base44 support, app-layer code to VGT/MapFlow.
- Independent Security Audit page — the full three-tier ownership model, all Base44-managed vs app-owned controls, MFA findings with fixes, and OWASP ZAP scan results are published at /independent-security-audit so an independent auditor can review them.
Data residency & scope
Roboshadow operates as a monitoring service — it scans endpoint metadata and application posture, not citizen data. No citizen PII is processed or stored by Roboshadow. The monitoring scope is the operator estate and the application security surface.
Proactive monitoring is a detection and remediation control, not a preventive barrier. It ensures that when a vulnerability or misconfiguration is introduced (by a new deploy, a new device, or a configuration change), it is found and fixed quickly — typically before an attacker can exploit it. Combined with the weekly InfoSec posture runner (which checks the app's own configuration) and the Independent Security Audit page (which documents the three-tier ownership model), MapFlow's security posture is continuously verified, not just attested at procurement.
Independent Security Audit & MFA Hardening (2026-08-27)
Three MFA findings identified and fixed; full audit reference published
Purpose
An internal security review on 2026-08-27 identified three findings in the custom TOTP MFA layer (the second-factor authentication MapFlow adds on top of Base44's platform-managed auth). All three have been fixed. The findings and fixes are documented on the Independent Security Audit page (/independent-security-audit) so an independent auditor can review them.
Findings & fixes
- Finding 1 (Fixed — High): TOTP secrets were stored in plaintext — the base32 secret was stored directly in the UserMFA entity, so a database compromise would expose every MFA secret. Fix: secrets are now AES-256-GCM encrypted at rest using a key derived from the MFA_SECRET_KEY environment secret. Legacy plaintext records are transparently re-encrypted on the next successful verification (backward-compatible migration).
- Finding 2 (Fixed — High): Backup codes were 'hashed' with btoa() (Base64 encoding) — trivially reversible with atob(). Fix: backup codes are now SHA-256 hashed with a per-code 16-byte random salt (format: base64(salt):base64(hash)). Verification uses constant-time comparison. The old base64 format fails closed (rejected).
- Finding 3 (Fixed — Medium): No rate limiting on MFA code attempts — a 6-digit TOTP code (1M combinations) could be brute-forced. Fix: after 5 consecutive failed attempts, the account is locked for 15 minutes (failed_attempts counter + locked_until timestamp on the UserMFA entity). Successful verification resets the counter. Lockout returns HTTP 423.
- Independent Security Audit page — the full audit reference is published at /independent-security-audit, documenting the three-tier security posture (Roboshadow / Base44 / VGT-MapFlow), all Base44-managed vs app-owned controls, the three MFA findings with fixes, and OWASP ZAP scan results.
- Salesforce vs MapFlow InfoSec comparison — a detailed comparison of MapFlow's sovereign security posture against Salesforce's native security (data residency, encryption, CLOUD Act exposure, MFA, audit trails, access control) is available at /salesforce-infosec-comparison.
Data residency
The MFA secret encryption key (MFA_SECRET_KEY) is a Base44 platform secret stored in the platform's secrets management, handled entirely server-side and never delivered to the browser. TOTP secrets are encrypted at rest in the UserMFA entity; backup codes are salted-hashed; rate-limiting state (failed_attempts, locked_until) is stored alongside the encrypted secret. No citizen data is involved in the MFA layer.
These fixes strengthen the custom MFA layer that sits on top of Base44's platform-managed authentication (email/password, OAuth, registration OTP). Base44's own registration OTP (email verification) was not affected — only the custom TOTP MFA layer that MapFlow adds for admin-gated second-factor authentication. The Independent Security Audit page (/independent-security-audit) is the authoritative reference for auditors reviewing these findings.
Vulnerability Disclosure Policy
MapFlow welcomes responsible disclosure of security vulnerabilities from independent researchers. If you believe you have identified a security issue in the MapFlow platform, its documentation, or its published cryptographic controls, please report it responsibly and in confidence to info@vgt-data-consultancy.co.uk. We ask that you give us reasonable time to investigate and remediate before any public disclosure. Reports made in good faith in accordance with this policy will not result in legal action against the reporter. This channel is for vulnerability reports only — for general support, please use the in-app support ticket facility.
Alignment & Caveats
- Hosted within pre-accredited infrastructure. MapFlow runs natively within pre-accredited, enterprise-grade Infrastructure and PaaS environments. The Base44 application platform (UI / orchestration layer) maintains independent SOC 2 Type II, ISO/IEC 27001, and GDPR certifications and is hosted explicitly in the United Kingdom. The UK Sovereign Postgres staging layer holds ciphertext PII only; the encryption key never leaves the operator's Local Proxy (DPAPI-held), so the staging operator cannot be compelled to disclose plaintext it does not hold. MapFlow's own application-layer controls (RLS, MFA, PII scanning, ciphertext-transit) are implemented and internally assured (see Security Testing & Assurance) but have not yet undergone a standalone ISO 27001 / Cyber Essentials Plus audit of the application itself — the infrastructure it runs on, however, is independently certified. We are transparent about this distinction so buyers can assign liability accurately rather than absorbing 100% of it.
- Base44 is a US-jurisdiction company (Oregon), Israel-founded — orchestration is US, app metadata is UK, citizen data is blind to Base44. Base44 Inc. is a company operating under United States jurisdiction, founded in Israel with its core development Israel-based and its PaaS / orchestration engineering based in Oregon, USA — so the US CLOUD Act applies to Base44 as a US-jurisdiction orchestration entity. MapFlow addresses this directly via a strict jurisdictional split: (1) Orchestration / PaaS — Base44, US-jurisdiction (Oregon); (2) App metadata — MapFlow's managed MongoDB, authentication, serverless runtime, file storage, and orchestration secrets are hosted explicitly in the United Kingdom; (3) Citizen data — entirely blind to Base44, controlled exclusively by MapFlow and residing only on UK Sovereign infrastructure (the UK Sovereign Postgres staging layer, ciphertext only) or the Local estate (the operator's Local Proxy, DPAPI/TPM-bound key), in AES-256-GCM encrypted form. In MapFlow's posture the Base44 platform hosts the user interface and orchestrates the flows (dispatching copy/load jobs, resolving Salesforce tokens, directing batches). It never holds plaintext PII, ciphertext PII, the PII encryption key, or any LLM API key — in volatile memory or in persistent storage. Ciphertext PII at rest lives only in the UK Sovereign Postgres staging layer; Base44's managed MongoDB and file storage never hold a single ciphertext PII value. Base44 only ever carries ciphertext in volatile memory in transit while orchestrating a read or write (streaming source rows to the staging Postgres, or staging rows to Salesforce), and during backup generation the ciphertext payload is built in volatile RAM and streamed straight to the connected cloud storage without being persisted in Base44. A US CLOUD Act production order against the US-parent platform therefore returns app metadata and non-PII artefacts only — the platform holds no plaintext PII and no ciphertext PII to disclose. When AI is enabled, prompts are assembled and the UK-sovereign LLM is called from the Local Proxy via the Sovereign Inference Shuttle, so no plaintext prompt or LLM key transits the US-parent platform.
- UK territorial sovereignty — the US CLOUD Act cannot, on its own, seize data held only by a UK-only entity. Under the UK Companies Act 2006 and the UK GDPR, a cloud provider registered exclusively in the UK, owned by UK citizens, and having no US operations is legally bound only by UK domestic law — a US court warrant (including a US CLOUD Act production order) holds no legal authority over an independent UK business. The US CLOUD Act cannot, on its own, seize a copy of data held only by such a UK-only entity. MapFlow's UK Sovereign Postgres staging provider and the UK-sovereign LLM providers (Civo, relaxAI) are UK-registered, UK-owned, with no US operations, so they are outside US CLOUD Act jurisdiction entirely; the only US-parent platform in MapFlow's data path is Base44, and it carries ciphertext and non-PII metadata only. UK domestic law (e.g. an Investigatory Powers Act warrant) remains the governing framework for any lawful disclosure request to the UK providers — and even then, the staging Postgres holds ciphertext PII only (the key never leaves the operator's Local Proxy), so a UK production order would likewise return ciphertext, not plaintext.
- Third-party services. The UK Sovereign Postgres provider and ConvertAPI are independent third parties. Their security posture is governed by their own certifications and published terms. The UK Sovereign Postgres provider is UK-registered and UK-owned with no US operations, so it is bound only by UK domestic law (see the territorial-sovereignty caveat above); MapFlow additionally configures it to hold ciphertext PII only. ConvertAPI is a non-default alternative that routes bytes through a third-party cloud API and requires its own InfoSec review and sign-off; where an engagement prohibits any third-party sub-processor for document content, the Local Proxy toolchain (or compression_scope = 'none') is selected and ConvertAPI is removed from the data path. The Local Proxy and document-compression toolchain are NOT third-party sub-processors: the proxy runs inside the council's own network as an outbound-only TLS 1.3 tunnel (no inbound ports, no external sub-processor in either flow, documents never touch the staging Postgres).
- Backup & Recovery key storage. The Master Recovery Key (the PII encryption key) is stored as a Base44 platform secret, or optionally the UK Sovereign Postgres Vault — NOT in a password manager. Platform secrets are handled entirely server-side, encrypted via AES-256-GCM, and never reach a browser or external sub-processor, so the password manager is removed from the backup-recovery trust boundary entirely. Operators may additionally bind the Local Proxy's copy of the key to the physical TPM 2.0 chip on the proxy host by enabling Windows Credential Guard, making the operational key hardware-bound (un-sealable only on that specific motherboard); a raw copy of the Master Recovery Key is escrowed to IT's own enterprise vault as the disaster-recovery break-glass path, so if the proxy hardware (and its TPM) is destroyed, IT can re-seal the same key onto a replacement host and all previously-encrypted ciphertext remains recoverable. The raw key never persists on the proxy host after provisioning and never reaches the Base44 platform.
- Client responsibilities. Clients are responsible for the security of their source databases, Salesforce orgs, and the credentials they supply. MapFlow never stores source database passwords persistently beyond the lifetime of a generated, time-bombed, revocable script.
- Customer references. Customer references — including any UK public-sector engagements using the underlying Base44 platform, directly or via a vendor — are available from the platform provider on request. MapFlow does not publish customer identities in this statement.
- Plaintext in the Query Console & Table Viewer is volatile, not stored — no CLOUD Act risk. The Query Console and the Postgres Table Viewer can display decrypted plaintext PII, but only when an administrator has provisioned an active, MFA-gated DecryptionSession (and, for the Table Viewer, only after the mandatory monthly Salesforce re-authentication is valid). When that session is active, decryption is performed on the operator's Local Proxy (DPAPI-held key) and the plaintext is delivered to the browser in volatile memory for the duration of the query only — it is never written back to the UK Sovereign Postgres staging layer, never persisted to the Base44 backend, and never logged. The staging Postgres remains in its ciphertext-at-rest state throughout; the Base44 platform only carries the ciphertext and the (transient) decrypted response over the encrypted session. Because no plaintext PII is persisted anywhere in the cloud — staging Postgres, Base44 managed database, file storage, or logs — a US CLOUD Act production order against the US-parent platform returns ciphertext only; the plaintext exists solely in the operator's volatile RAM for the life of the authenticated session and is discarded on session end. This is the Zero-Trust decryption posture: plaintext is visible on demand to an authorised, authenticated human, but never stored, so there is no persistent plaintext for any cloud provider to disclose.
- Tenancy boundary — intra-tenant object-level authorization, not multi-project grouping. MapFlow's security tenancy boundary is the single Base44 tenant (app instance): cross-tenant isolation is enforced by database-layer Row-Level Security, so one tenant's data cannot be read, created, updated, or deleted by a user of another tenant. A 'Multi-Project' workspace — several council engagements grouped inside one tenant for a System Integrator's or council family's operational convenience — is an organisational grouping, not a security tenancy boundary. Project membership is an object-level access scope WITHIN the tenant (which engagement's records a given user may see); the tenant itself remains the isolation unit, and grouping engagements neither creates, weakens, nor replaces the database-enforced RLS boundary. MapFlow treats any Multi-Project workspace as a client/SI convenience and documents it as such for InfoSec; the security assurance rests on intra-tenant object-level authorization (RLS within the single app instance), not on the multi-project grouping. A current Base44 attestation covering INTRA-tenant object-level authorization (RLS enforcement within a single tenant / app instance) may be requested from the platform provider on request to corroborate this boundary; such an attestation is distinct from, and not a substitute for, any multi-project grouping control.
- Review cadence. This statement is reviewed at least annually and on any material architectural change.
Questions about this statement?
For deeper technical detail, a controls spreadsheet, or to arrange a security review call, contact the MapFlow team. The product synopsis and full app are also available.