MAST GRC Security Whitepaper

MAST GRC is a multi-tenant SaaS platform for managing compliance programmes, risks, audits, policies, training, incidents and data subject requests across multiple management-system standards. Security is enforced primarily at the data layer: no request can read or write a record outside the caller's workspace, regardless of what the client sends. The controls summarised on the Security page are described here in implementation detail.

The application is served from a globally distributed edge runtime that renders the user interface and executes server functions close to the user. Persistent state lives in a managed PostgreSQL cluster with regional placement, alongside an object store for evidence and documents. There are no long-lived application servers holding customer data; all state transitions go through authenticated server functions or the database's own API with the caller's identity attached.

Background work — reminder digests, nightly integrity reconciliation, notification scans — runs as scheduled jobs against authenticated endpoints, with results written to auditable job records.

• Every tenant-scoped table carries a tenant_id and has row-level security enabled with explicit policies; tables without a matching policy are unreachable by design.
• Membership and role checks run through security-definer functions that require a non-null tenant match, so a missing or forged tenant claim fails closed rather than widening access.
• Privileged service credentials are never exposed to the browser and are only used inside server-side handlers after the caller has been verified.
• Object storage uses per-tenant path prefixes enforced by storage policies, so signed URLs cannot be pivoted to another workspace's files.
• A nightly integrity job reconciles tenant scaffolding and reports drift per tenant, giving operators a standing check that isolation and provisioning stay consistent.

Users authenticate with email and password, social sign-in, or SAML 2.0 single sign-on. Time-based one-time-password MFA is available on every account and can be enforced workspace-wide by an administrator. Sessions use short-lived access tokens with refresh rotation.

Inside a workspace, permissions are role-based (owner, admin, GRC manager, contributor, auditor, employee) and roles are stored in a dedicated table — never on the user or profile record — so a compromised profile update cannot escalate privileges. Every privileged action is written to an activity log visible to workspace administrators.

• In transit — TLS 1.2 minimum, TLS 1.3 preferred, HSTS enabled on all MAST domains.
• At rest — AES-256 for the database, object storage and backups.
• Secrets — API keys and connector credentials are held in a managed secret store, injected only into server-side execution contexts, and never written to logs.
• Connector tokens — third-party OAuth tokens are encrypted with a dedicated key before storage and decrypted only inside the server function that uses them.
• Backups — encrypted, redundant, point-in-time recovery, with restore testing.

Evidence files are uploaded directly to tenant-scoped storage paths. Downloads use short-lived signed URLs issued only after a policy check. Evidence records keep an immutable link to the control, audit or finding they support, plus uploader identity and timestamp, so audit trails survive later edits. Deleted evidence is removed from production storage and ages out of backups on the standard cycle.

• Change control through reviewed pull requests; no direct production edits.
• Automated static analysis, dependency scanning and a database security linter that flags missing policies, over-broad grants and anonymous access before release.
• Continuous automated security review of the schema and access rules, with findings tracked to closure.
• Migrations are versioned and applied forward-only, with grants written alongside every new table.

Application errors are captured centrally with tenant context and reviewed by the operations team. Authentication events, admin actions and job outcomes are logged and retained for at least 12 months. Anomalies — repeated permission denials, unusual admin activity, failed scheduled jobs — raise alerts to the on-call rota.

Storage and database layers are replicated across availability zones with point-in-time recovery. The Platform targets an RTO of 4 hours and an RPO of 15 minutes. Continuity and restore plans are exercised on a defined schedule, and the results are available to customers under NDA. The Platform's own BCMS module is used to manage this programme.

Data minimisation is applied to defaults: the Platform never requires special-category data, notification content links back to the app rather than embedding record detail, and AI features are opt-in per workspace with prompt content excluded from provider training. Personal data processing terms are set out in the Data Processing Agreement, and the parties involved are listed in the sub-processor list.

Certificates, attestation reports, penetration-test summaries and completed security questionnaires are available under NDA. Email security@mastcgroup.com or use the contact form and choose Security. Vulnerability reports are handled under the responsible disclosure process on the Security page.