Trust centre · POPIA-native · SOC 2 Type II in progress
Security built into
the architecture.
Defence in depth from edge to embedding. TLS 1.3 in transit, AES-256 at rest, every byte processed in AWS af-south-1 (Cape Town). Multi-tenant isolation via PostgreSQL row-level security. PII scrubbed before any document content reaches an AI pipeline. Immutable audit logs that prove POPIA Section 19 compliance.
POPIA Section 19 enforced
AWS af-south-1 only
MFA enforced for staff
BYOK on Enterprise tier
01 · Defence in depth
Six security pillars. Every product. Every cluster.
Security is not a feature on the sonofgraig platform — it is the architecture itself. Each of the six pillars below is implemented at the infrastructure or database layer, not by application-level checks. That distinction matters: a misbehaving service cannot bypass a firewall, a residency rule, or a row-level security policy.
Pillar 01
Data residency
All production data is processed and stored in AWS Cape Town (af-south-1). Data residency is enforced at the infrastructure layer — not by contract.
- POPIA Section 72 enforced by VPC, not policy
- Self-hosted Qdrant inside af-south-1 VPC
- Egress allow-listed for approved endpoints
Pillar 02
Encryption everywhere
TLS 1.3 for everything moving. AES-256 for everything at rest, enforced by AWS at the storage layer. Secrets never sit in code or environment files.
- TLS 1.3 with strong cipher suite enforcement
- AES-256 at rest on Postgres, Qdrant, S3
- HashiCorp Vault & AWS Secrets Manager
- BYOK encryption keys on Enterprise tier
Pillar 03
Identity & access
Role-based access at the application layer. Row-level security at the database layer. The principle of least privilege is enforced for every internal service component.
- Supabase RLS scopes every tenant query
- MFA mandatory for all staff in production
- Short-lived JWTs with token rotation
- SSO/SAML on Enterprise tier
Pillar 04
PII protection in AI
South-African PII is detected and redacted by middleware before any content reaches an embedding model, vector store, or external LLM API. AI safety is a pipeline guarantee, not a prompt instruction.
- Detects ID numbers, phones, emails, passports
- Runs synchronously before vectorisation
- Tested in CI as part of every deployment
- Zero raw PII transmitted to external models
Pillar 05
Auditability
Every RAG query, every agent execution, every administrative action is logged immutably. Hashes are stored — not raw content — so the audit log is a compliance record and not a secondary copy of personal information.
- SHA-256 hashes of user IDs and queries
- PostgreSQL rules prevent log deletion
- Synchronous logging — no race conditions
- Records POPIA s.11 processing basis
Pillar 06
Edge & network
Cloudflare sits in front of every public endpoint with WAF, bot protection, rate limiting, and DDoS mitigation. Backend services run in private subnets with no public IPs.
- Cloudflare WAF with managed rule sets
- Per-IP and per-org rate limiting
- VPC private subnets for all backends
- ALB-only ingress, no direct DB exposure
02 · Architecture
Five layers. One enforced posture.
From the edge router that receives a request to the AWS storage block that returns an embedding, every layer of the sonofgraig platform contributes a security control. The diagram below traces a single tenant request from Cloudflare into af-south-1 and back, naming every component and the safeguard it provides.
L01
Edge — Cloudflare global network
Every request hits Cloudflare first. WAF rules block OWASP Top 10 patterns. Bot protection neutralises automated scraping. Rate limits are applied per-IP and per-organisation. DDoS mitigation runs continuously across 300+ points of presence.
Cloudflare WAF
DDoS L3/L4/L7
Bot Management
Rate limiting
L02
Ingress — TLS 1.3 termination & auth
TLS 1.3 is terminated at the AWS Application Load Balancer in af-south-1. Authentication tokens (short-lived JWTs) are validated. The organisation ID is extracted from the JWT claims and propagated through the request lifecycle for downstream RLS scoping.
TLS 1.3
AWS ALB
JWT (short-lived)
MFA enforced
L03
Application — PII scrubbing & AI gateway
Document content passes through the PII scrubber before it ever reaches an embedding model. South-African personal identifiers are detected and redacted. The LiteLLM gateway sits between application services and any external LLM provider, enforcing that PII-scrubbed content is the only payload that leaves our network.
PII Scrubber middleware
LiteLLM gateway
FastAPI
tRPC
L04
Data — Multi-tenant isolation via RLS
PostgreSQL row-level security policies scope every query to the authenticated organisation automatically. There is no application-layer filter to forget. Qdrant uses one named, independently encrypted collection per tenant. Cross-tenant access requires a database root credential, not an application bug.
PostgreSQL 16
Supabase RLS
Qdrant per-tenant
AES-256 at rest
L05
Infrastructure — AWS af-south-1 only
All production workloads run in Cape Town. EC2, RDS, S3, Secrets Manager, EKS — every service is anchored to af-south-1. The VPC has no internet gateway by default; egress to approved endpoints is allow-listed. Infrastructure is defined in Terraform — every change is reviewable and auditable.
AWS af-south-1
EKS Kubernetes
Terraform IaC
VPC private subnets
Prometheus + Grafana
03 · Compliance & certifications
Compliance posture, documented honestly.
We list every framework with its real status — active, in progress, or planned. We will never claim a certificate that has not been issued. The South African market deserves honest compliance reporting, and our enterprise procurement counterparties require it.
Framework
What it covers
Status
POPIA
Act 4 of 2013 · ZA
South African Protection of Personal Information Act. We comply across Section 11 (lawful processing), Section 13 (data minimisation), Section 19 (security safeguards), Section 22 (breach notification), Section 26 (special PI), and Section 72 (data residency). Information Officer registered with the Information Regulator.
Active
SOC 2 Type II
AICPA · Trust Services
Annual third-party audit of security, availability, and confidentiality controls — required by most enterprise procurement processes globally. Audit process initiated; controls implementation is the current phase. Vanta is our continuous-control monitoring platform during readiness.
In progress
ISO/IEC 27001
Information Security
International information security management standard. Provides enterprise customers with assurance of systematic security controls across 14 control domains. Gap analysis complete; ISMS scope defined for the platform; Stage 1 audit planned.
Planned · 2026 H2
EU AI Act readiness
Regulation (EU) 2024/1689
Risk classification and documentation of AI systems per the EU AI Act taxonomy. Required for customers serving EU data subjects or operating in EU jurisdictions. Risk register maintained; technical documentation produced for each platform AI system.
Readiness phase
GDPR alignment
Regulation (EU) 2016/679
Data Processing Agreements and privacy-by-design controls for customers with EU data subjects. POPIA alignment provides most baseline GDPR controls; Standard Contractual Clauses available for cross-border data transfer where lawful.
Aligned
PAIA manual
Promotion of Access to Information Act, ZA
Promotion of Access to Information Act manual published and available to data subjects. Covers categories of records held, requestor procedure, and the Information Officer’s contact details.
Published
B-BBEE certification
B-BBEE Act, ZA
Broad-Based Black Economic Empowerment certificate. Available to enterprise procurement teams on request — required for many South African enterprise and public-sector customers as part of supplier assessment.
Certified
04 · Security controls
The control catalogue. Implementation, not aspiration.
Security questionnaires move faster when answers are precise. The controls below are grouped by domain and describe what is implemented today — the technology, the enforcement point, and the operational frequency where applicable.
A — Cryptography
Encryption & key management
TLS 1.3 for all data in transit. Strong cipher suites enforced; legacy protocols disabled.
AES-256 at rest on PostgreSQL, Qdrant, S3, and EBS volumes.
HashiCorp Vault and AWS Secrets Manager for credentials. No hardcoded secrets in source.
BYOK (bring-your-own-key) encryption available on Enterprise tier.
JWT rotation on short-lived authentication tokens.
B — Identity
Access & authentication
Role-based access control at the application layer with four built-in roles (Admin, Builder, Viewer, Compliance).
Supabase Row-Level Security at the database layer — every query is scoped to the authenticated organisation.
MFA required for all sonofgraig staff accessing production systems.
SSO / SAML available on Enterprise tier; customers can enforce MFA for their users.
Principle of least privilege applied to every internal service component.
C — Data
Multi-tenant isolation
Per-tenant Qdrant collections — each is independently encrypted; the collection name pattern is
{org_id}_{kb_id}.Postgres organisation_id column on every customer-data table; RLS policy enforces scoping with no application code involvement.
Dedicated inference endpoints for Enterprise tier customers requiring total compute isolation.
Customer data residency controls — data never leaves South African infrastructure for any tenant.
D — AI safety
PII scrubbing & pipeline integrity
SA-specific PII detection for ID numbers, mobile numbers, email addresses, and passport numbers — applied before any document is embedded.
Synchronous middleware — content cannot reach the embedding model unless the scrubber returns clean output.
LiteLLM gateway normalises and inspects every external LLM call. PII-scrubbed payloads only.
Tested in CI — synthetic PII test corpus runs on every deploy. A PII leak fails the build.
Customer data is never used to train shared models. Tenant fine-tunes are tenant-scoped.
E — Audit
Immutable logging
Synchronous query-level audit log — written before the response is returned. A missed log fails the operation.
SHA-256 hashes of user IDs and queries — the audit log is a compliance record, not a secondary data copy.
PostgreSQL deletion rules reject log row deletes — append-only semantics.
POPIA Section 11 processing basis recorded against every operation.
F — Network
Edge & perimeter
Cloudflare WAF with managed OWASP rule sets; bot management and rate limiting per IP and per organisation.
VPC private subnets for databases and application servers — no public IPs on backend infrastructure.
AWS Application Load Balancer as the sole ingress point. All other traffic blocked at the security-group level.
Egress allow-listing for approved external endpoints; default-deny on outbound traffic.
G — Operations
Monitoring & observability
Prometheus & Grafana for infrastructure metrics, request rates, error rates, and SLO tracking.
Sentry for frontend and backend error tracking and session replay.
OpenTelemetry for distributed tracing across all services — vendor-agnostic instrumentation.
Langfuse (self-hosted) for LLM observability — prompt traces, token costs, evaluation scores.
H — Engineering
Secure SDLC
Mandatory peer review on every pull request to a protected branch.
Static analysis (SAST) and dependency scanning (SCA) on every commit. Critical findings block merge.
Infrastructure as Code via Terraform — every change reviewable.
Annual penetration testing by an external assessor; remediation tracked to closure.
05 · Incident response
If the worst happens, we already know what we’re doing.
The breach response procedure is documented, rehearsed annually, and aligned to POPIA Section 22. The Information Regulator is notified within 72 hours of confirmed breach. Affected data subjects are notified as soon as reasonably possible. The timeline below is the public version of our internal runbook.
T+0 · Detection
Containment & assessment
Detection sources include automated alerts (Sentry, Cloudflare, AWS GuardDuty), customer reports via tumiso@sonofgraig.com, and internal review. The on-call engineer escalates to the Information Officer immediately. Affected systems are isolated. Scope of exposure is assessed: what data, whose data, how it was accessed. A formal incident record is opened.
T + 24 hours
Internal review & notification decision
The Information Officer determines whether the incident creates a risk to affected data subjects. If personal information has been accessed by an unauthorised person, formal notification is required under POPIA Section 22. Legal counsel is engaged where appropriate. Customer Information Officers of impacted tenants are contacted directly.
T + 72 hours
Information Regulator notification
The Information Regulator of South Africa is formally notified within 72 hours of confirmed breach. The notification includes nature of the breach, categories of personal information affected, estimated number of data subjects impacted, likely consequences, and the measures taken or proposed to address the breach.
As soon as reasonably possible
Data subject notification
Affected data subjects are notified directly by email and in-app where contact information is available, unless a public communication is more effective. The notification describes the breach in plain language, the categories of personal information involved, the likely consequences, and the steps the data subject can take to protect themselves.
Post-incident
Root-cause analysis & remediation
A blameless post-mortem is conducted within 14 days. Root cause is identified, remediations are tracked to closure, and platform-wide changes are made to prevent recurrence. A public incident report is published for material incidents on the status page. The breach scenario test is revised based on lessons learned.
06 · Shared responsibility
Where sonofgraig stops and you begin.
A platform secures the platform. The customer secures the customer’s configuration and use. The boundaries below are explicit so there are no surprises for an enterprise security team performing a third-party risk assessment.
07 · Sub-processors
A complete list of who touches what.
A sub-processor is any third party that may process personal information on our behalf. The list below is the entire current set; we will notify customers in writing before adding a sub-processor in line with the commitments in our Data Processing Agreement.
Sub-processor
Region
Purpose
Data type
Amazon Web Services
af-south-1 · ZA
Primary infrastructure — EC2, S3, RDS, Secrets Manager, EKS, VPC.
All production data
Cloudflare
Global edge
Edge CDN, WAF, DDoS mitigation, bot protection, rate limiting.
Request metadata
Supabase
af-south-1 · ZA
Managed PostgreSQL, auth primitives, realtime, storage. RLS-scoped multi-tenancy.
Tenant data
Anthropic / Claude API
US
LLM inference for agent execution and RAG generation. PII-scrubbed payloads only.
Scrubbed prompts
Stripe
US / EU
Subscription management, ZAR payment processing, invoicing, customer billing portal.
Billing only
Resend
EU / US
Transactional email — onboarding, billing alerts, team invitations.
Email + name
Sentry
EU region
Error tracking and performance monitoring. PII-scrubbed via SDK config.
Error metadata
Vanta
US
SOC 2 / ISO 27001 readiness — continuous control monitoring, evidence collection.
Control metadata
HubSpot
EU region
CRM for enterprise deal tracking and account onboarding.
Business contacts
Customers using a sonofgraig product on the Enterprise tier may opt out of any non-essential sub-processor through their Data Processing Agreement. Where a sub-processor sits outside af-south-1, transfer is governed by Standard Contractual Clauses or an equivalent lawful basis under POPIA Section 72 and explicit customer consent.
08 · Documentation & contact
For procurement, legal, and security teams.
Most third-party risk assessments require the same set of documents. We have packaged these for download — and for any document you cannot find, your account team can supply it under NDA on request.
Data Processing Agreement
Our DPA covers all processing activities, legal basis, security controls, sub-processors, and transfer mechanisms. Pre-signed and ready to counter-sign.
Download DPA
SOC 2 status letter
A current letter from our auditor describing the SOC 2 Type II readiness phase. Available under NDA. Final report will be issued at audit completion.
Request letter
Security questionnaire
Pre-completed responses to standard questionnaires including CAIQ, SIG-Lite, and a full POPIA Section 19 questionnaire. Saves your team weeks.
Request package
Report a vulnerability
Found a security issue? Report it directly to our team. We respond to all reports within one business day and credit reporters in our public security advisories where appropriate.
tumiso@sonofgraig.com
Information Officer
For all POPIA-related queries — data subject access requests, processing complaints, and consent inquiries. Our Information Officer is registered with the Information Regulator.
tumiso@sonofgraig.com
Status & uptime
Live platform status across all five clusters, historical incident reports, and scheduled maintenance windows. Subscribe via RSS, email, or SMS.
status.sonofgraig.com
09 · Frequently asked
Questions enterprise procurement always asks.
If your security team is preparing for a vendor review, the answers below cover ninety per cent of what gets raised. For anything more specific, your account team can route the question to engineering directly.
Where does our data physically reside?
All production data is processed and stored in AWS af-south-1 (Cape Town, South Africa). Data residency is enforced at the infrastructure layer through VPC and storage configuration — it is not a contractual claim that depends on application behaviour. The only data that ever leaves af-south-1 is PII-scrubbed prompts sent to external LLM providers (when your tenant is configured to use them), and minimal payment metadata sent to Stripe.
Do you train your shared models on customer data?
No. Customer data is never used to train any model that is shared across tenants. Tenant fine-tunes are tenant-scoped — the resulting weights are accessible only to the originating organisation. Aggregated, anonymised usage telemetry (which prompts perform best, which models succeed at which tasks) is collected to improve platform suggestions, but raw customer content is never part of that telemetry.
How is one tenant’s data prevented from leaking to another?
Two enforcement layers, neither of which depends on application code being correct. (1) PostgreSQL row-level security policies on every customer-data table — every query is automatically scoped to the authenticated
organisation_id. (2) Qdrant uses a separate, independently encrypted collection per tenant, named {org_id}_{kb_id}. Cross-tenant access requires a database root credential, not an application bug. Enterprise tier customers may also receive dedicated inference endpoints for total compute isolation.What happens when an external LLM provider receives a request?
All external LLM calls flow through the LiteLLM gateway, which sits between application services and any third-party model provider (such as Anthropic). Before the gateway is reached, content has already passed through the PII scrubber middleware. South-African personal identifiers — ID numbers, mobile numbers, email addresses, passport numbers — are detected and redacted. The provider receives only PII-scrubbed payloads and sees no raw personal information from your documents.
What is your SLA and how do you measure it?
SLA is tier-dependent. Starter — 99.5% uptime, best-effort support, 48-hour response time. Growth — 99.9% uptime, business-hours support, 8-hour response time. Enterprise — 99.95% uptime, 24/7 dedicated support, 1-hour response time, assigned Customer Success Manager. Uptime is measured on a per-cluster basis on our public status page, calculated monthly with credit issued automatically against breaches.
Can we bring our own encryption keys?
Yes, on the Enterprise tier. BYOK (bring-your-own-key) lets your organisation manage its own master encryption keys via AWS KMS, retaining the ability to revoke at any time. Combined with custom data residency controls and dedicated inference endpoints, it gives the highest isolation tier available on the platform.
Do you support SSO and SCIM for user management?
SSO/SAML is available on the Enterprise tier. SCIM-based user provisioning and de-provisioning is on the platform roadmap; Enterprise customers can request a status update from their account team. Until SCIM ships, role assignment is performed in the team management UI by an organisation Admin.
What is your patching and dependency policy?
All container images are built from minimal, regularly rebuilt base images. Critical CVEs are remediated within 72 hours of public disclosure. High-severity CVEs are remediated within 7 days. SCA scanning runs on every commit and blocks merge for unresolved critical findings. Production dependencies are pinned and reproducible builds are enforced.
How do we delete our data when we leave?
On contract termination, all tenant data — relational records, vector collections, object storage, and tenant-specific fine-tuned model weights — is purged from production systems within 30 days. Backup retention extends this period to a maximum of 90 days, after which the data is unrecoverable. A deletion attestation is issued to the customer’s Information Officer on request. Audit log records are retained in hashed form for the regulatory retention period required by POPIA and applicable financial-records legislation.
Are you B-BBEE certified and CIPC registered?
Yes — sonofgraig is B-BBEE certified and CIPC registered. All commercial documentation is available to enterprise procurement teams in support of supplier on-boarding.
For procurement & legal teams
Need a complete due-diligence package?
DPA, SOC 2 status letter, B-BBEE certificate, PAIA manual, security questionnaire responses (CAIQ & SIG-Lite), and architecture diagrams under NDA. Sent within one business day.