CredCheck data processing agreement (template)

This Data Processing Agreement ("DPA") is between:

• [[CUSTOMER LEGAL NAME]], [[ADDRESS]] ("Customer", the controller), and
• [[LEGAL ENTITY NAME]], [[REGISTERED ADDRESS]], Lagos, Nigeria, RC [[RC NUMBER]] ("CredCheck", the processor).

It forms part of the CredCheck Platform Terms or other agreement between the parties (the "Agreement"), effective [[EFFECTIVE DATE]].

1. Definitions

Terms such as personal data, processing, controller, processor, data subject, personal data breach and supervisory authority have the meanings given in Applicable Data Protection Law.

Applicable Data Protection Law means the laws that apply to the processing, including:

• the Nigeria Data Protection Act 2023 and NDPC regulations and directives
• the EU/UK GDPR where applicable
• South Africa's POPIA
• Kenya's Data Protection Act 2019
• Ghana's Data Protection Act 2012

Customer Personal Data means personal data in Customer Data processed by CredCheck for the Customer under the Agreement, as described in Annex 1.

This DPA does not cover data CredCheck processes as a controller. That includes consumer verification, report and reward data, portal account and security data, and billing data, which are covered by CredCheck's privacy policies.

2. Roles and instructions

1. The Customer is the controller, and CredCheck is the processor, of Customer Personal Data. Where the Customer is itself a processor for a third party, CredCheck is its sub-processor, and the Customer confirms its own controller has authorised this.
2. CredCheck processes Customer Personal Data only on the Customer's documented instructions. Those instructions are this DPA, the Agreement, and the Customer's configuration and use of the Platform. The only exception is where the law requires otherwise, in which case CredCheck will tell the Customer first unless the law forbids it.
3. CredCheck will tell the Customer if, in its opinion, an instruction breaks Applicable Data Protection Law.
4. The Customer is responsible for the lawfulness of the Customer Personal Data and its instructions, including giving notices to, and having a legal basis for, its distributors' and partners' contacts and users.

3. Confidentiality

CredCheck ensures that everyone authorised to process Customer Personal Data is bound by confidentiality, and has access only as needed for their role. Staff access to tenant portals runs through time-limited, reason-recorded, fully audited support sessions visible to the Customer.

4. Security

CredCheck implements the technical and organisational measures in Annex 2. They are designed to protect against accidental or unlawful destruction, loss, alteration, unauthorised disclosure or access, taking into account the state of the art, costs and risks. CredCheck may update the measures as long as overall protection is not materially reduced.

5. Sub-processors

1. The Customer gives general authorisation for CredCheck to use the sub-processors listed in Annex 3 and at [[SUBPROCESSORS URL]].
2. Configurable providers. The Platform supports several interchangeable providers per capability (for example SMS, payments, AI). CredCheck, and where the Platform allows the Customer, selects which are active. Only providers actually enabled for the Customer's processing receive Customer Personal Data.
3. CredCheck will give at least [[30]] days' notice of a new sub-processor, by updating the list and notifying subscribed account admins. The Customer may object on reasonable data protection grounds within that period. If the parties can't resolve the objection, the Customer may terminate the affected service and receive a pro-rata refund of prepaid fees.
4. CredCheck imposes data protection obligations on each sub-processor that are substantially equivalent to this DPA, and remains liable for its sub-processors' performance.

6. International transfers

1. CredCheck hosts the Platform in Germany (EU), and some sub-processors process data in other countries, as listed in Annex 3.
2. CredCheck will transfer Customer Personal Data outside the country of collection only in compliance with Applicable Data Protection Law. Depending on the route, the mechanism will be NDPA ss.41–43, GDPR Chapter V (for example the EU Standard Contractual Clauses), POPIA s.72, Kenya DPA Part VI or Ghana DPA requirements [[COUNSEL: attach or incorporate the applicable clauses by reference, including Module 2/3 SCCs and any NDPC-approved instrument]].

7. Assistance to the Customer

1. Data subject requests. Taking into account the nature of the processing, CredCheck will help the Customer respond to requests to exercise data subjects' rights. The Customer can access, correct, export and delete most Customer Personal Data directly in the portal and API. CredCheck will forward requests it receives that relate to Customer Personal Data to the Customer without undue delay and will not respond to them itself, unless instructed or required by law.
2. DPIAs and consultations. CredCheck will provide reasonable information to help the Customer carry out data protection impact assessments and prior consultations with regulators.
3. Records. CredCheck keeps a record of processing activities carried out for the Customer.

8. Personal data breaches

1. CredCheck will notify the Customer without undue delay, and in any event within [[48]] hours, after becoming aware of a personal data breach affecting Customer Personal Data. This lets the Customer meet the 72-hour regulator notification under NDPA s.40 and GDPR Art. 33.
2. The notice will include, as far as it is known: the nature of the breach, the categories and approximate numbers of data subjects and records, likely consequences, measures taken or proposed, and a contact point. Information may be provided in phases.
3. CredCheck will take reasonable steps to contain and remedy the breach, and will not notify regulators or data subjects about Customer Personal Data on the Customer's behalf without its agreement, unless the law requires it.

9. Return and deletion

1. During the term, the Customer can export its data through the portal and API [[ENGINEERING: confirm export coverage]].
2. Within [[90]] days after the Agreement ends, and following the export window in the Agreement, CredCheck will delete or anonymise Customer Personal Data. The exceptions are data it must keep by law, and backups, which are overwritten on their normal cycle of [[BACKUP RETENTION]] and stay protected by this DPA until deleted. CredCheck will confirm deletion in writing on request. [[PLANNED: tenant offboarding and deletion job]]

10. Audits and information

1. CredCheck will make available the information reasonably needed to demonstrate compliance with this DPA. This includes summaries of third-party penetration tests and security assessments, and on request this DPA's Annex 2 evidence.
2. Where that information is not enough, or a regulator requires it, the Customer may carry out an audit, or have one carried out by an independent auditor bound by confidentiality. The audit needs [[30]] days' notice, happens no more than once a year (unless following a breach or regulator request), takes place during business hours, and must not disrupt the Platform or other customers' data. Each party bears its own costs unless the audit reveals a material breach.

11. Liability

Liability under this DPA is subject to the limitations in the Agreement [[COUNSEL: data protection super-cap]].

12. Order of precedence and term

This DPA prevails over the Agreement on the processing of Customer Personal Data. It remains in force for as long as CredCheck processes Customer Personal Data.

Signed for the Customer: [[NAME, TITLE, DATE]] Signed for CredCheck: [[NAME, TITLE, DATE]]

Annex 1: details of processing

Annex 2: technical and organisational measures

Sources: docs/03-security.md, docs/02-architecture.md and the cited code. [PLANNED] means described in design documents but not verified in code.

Access control and identity

• Passwords hashed with Argon2id (64 MB memory, 3 iterations, parallelism 4), with constant-time checks against a dummy hash so sign-in does not reveal whether an account exists (apps/api/src/security/crypto.ts).
• TOTP multi-factor authentication. Mandatory for company admins and all platform staff (staff_users.mfa_enabled defaults to true). Recovery codes stored hashed.
• Short-lived access tokens (15 minutes by default) and rotating, revocable refresh tokens stored as SHA-256 hashes (sessions.refresh_token_hash). Refresh cookie is HttpOnly, Secure in production, SameSite=Lax, and scoped to /v1/auth (apps/api/src/auth/auth.controller.ts:29–36).
• Account lockout after failed attempts, sign-in attempt logging, and CAPTCHA (Cloudflare Turnstile) after repeated failures when enabled.
• Role-based access control for company, platform and regulator roles, enforced server-side by guards and policy checks.
• API keys: shown once, stored as hashes, prefixed, scoped, environment-bound, expirable and revocable (api_keys model).
• Staff impersonation: reason required, maximum 30 minutes, not refreshable, every audit row tagged, visible to the tenant (impersonation_sessions).

Tenant isolation

• Tenant scoping in the application layer, plus PostgreSQL row-level security with FORCE ROW LEVEL SECURITY on tenant tables.
• The runtime database role credcheck_app is NOSUPERUSER NOBYPASSRLS with DML-only grants. A query with a forgotten scope returns zero rows (fails closed).
• RLS write checks reject cross-tenant inserts and updates. Isolation is proven in automated end-to-end tests (docs/03-security.md §3.1).

Encryption

• In transit: TLS 1.2+ with HSTS, terminated at Cloudflare with origin certificates.
• At rest: provider volume encryption [[CONFIRM for Hetzner volumes, LUKS per docs]]. Field-level AES-256-GCM for MFA secrets, provider credentials, tenant code-signing keys, payment authorisation tokens and airtime phone numbers. Production refuses to start without a 32-byte key (crypto.ts:72–83).
• Code deliverable files are AES-256-GCM encrypted and delivered through expiring signed URLs. Authentication codes are stored only as SHA-256 hashes.
• Backups: nightly encrypted pgBackRest to object storage, point-in-time recovery, quarterly restore drills (infra/dr/).

Application security

• Zod input validation at every API boundary. Allowlisted output DTOs.
• Rate limiting per IP, device, API key and code, with 429 + Retry-After. Load shedding protects verification.
• HMAC-SHA256 signed webhooks with timestamp tolerance. HMAC-signed QR payloads with per-tenant keys.
• Uploaded images are magic-byte sniffed, size-capped, and fully decoded and re-encoded to WebP (removing metadata and appended payloads), then served from private storage through short-lived signed URLs (apps/api/src/storage/report-media.service.ts).
• Security headers on web apps (X-Frame-Options: DENY in infra/docker/Caddyfile). [PLANNED] Full CSP on all web apps.
• CI security gates: dependency audit, Semgrep, gitleaks, dependency review, IaC scanning. [PLANNED] External penetration test before launch (M15).

AI safeguards

• A single AI gateway enforces plan gates, kill switches, budgets and runaway guards.
• Text prompts are redacted for email addresses and phone numbers before being sent to a provider. Invocations are logged with redacted, truncated prompts, provider, model and cost (apps/api/src/ai/gateway.ts, redact.ts).
• Outputs are schema-validated and labelled as AI-generated. AI never changes a verification verdict.

Auditability and monitoring

• Append-only audit log of privileged changes: actor, action, object, before and after values, IP, request ID and impersonation ID. Tenants can see their own audit log.
• Metrics, SLO burn-rate alerting, on-call paging and synthetic probes in three African regions (docs/slo.md).
• Application logs: [[CONFIRM: Loki 90-day hot retention and archive period, per `docs/03-security.md` §7]].

Data minimisation and retention

• Consumer identifiers (device ID, IP, phone) are stored as hashes in scan records. [PLANNED] Keyed hashing (HMAC with a secret pepper).
• Raw scan events are partitioned by month and archived after 13 months, with checksummed archives before partitions are dropped (docs/runbooks/data-lifecycle.md).
• [PLANNED] Retention jobs for sessions, login attempts, webhook deliveries, notifications, AI invocations and expired code deliverables.

Organisational

• Least-privilege staff roles. Sensitive data masked by default in admin, with audited reveal.
• Secrets held in a secrets manager with per-environment scope. Never in code or CI logs.
• Confidentiality obligations for staff and contractors [[HR TO CONFIRM]]. Security and privacy training [[PLANNED]].
• Incident response runbooks with postmortems (docs/runbooks/incidents/). Breach notification process [[PLANNED: add regulator and customer notice steps]].
• Vulnerability disclosure policy and security.txt [PLANNED, M15].

Annex 3: sub-processors

The current list, with purpose, data, location and transfer mechanism, is maintained at subprocessors.md ([[PUBLIC URL]]) and incorporated by reference. Sub-processors that may receive Customer Personal Data under this DPA:

Payment providers (Paystack, Flutterwave, Stripe) process billing data for CredCheck as controller, not Customer Personal Data under this DPA.