The Trust Readiness Playbook
A sourced guide to what SOC 2, CBN AML/CFT, and NDPA actually require — and why Evidence Native Systems reduce the cost of proving compliance across all three.
This webpage is the canonical version. The PDF is provided for offline reading and sharing.
How to read this Playbook
This is a research publication, not a marketing page. It is organised so you can read it end to end or jump to the framework you are preparing for. Three conventions run through it:
- SOURCED — a statement anchored to a regulatory text, framework definition, or published standard.
- STACKWEAVER VIEW — our engineering position, clearly separated from sourced fact.
- ILLUSTRATIVE — a scenario used to make a mechanism concrete; not a representation of any specific client.
Every major section closes with Key Takeaways — three bullets an auditor, founder, or engineer can act on. The diagrams are original and reusable; the tables compare frameworks on the dimensions that actually change your evidence work.
SOC 2 is an attestation under AICPA standards; CBN AML/CFT is governed by the Money Laundering (Prevention and Prohibition) Act 2022 and CBN regulations; NDPA is the Nigeria Data Protection Act 2023, enforced by the NDPC. This Playbook summarises them; the statutes and framework documents remain authoritative.
Context: three frameworks, one evidence problem
Most regulated African fintechs face SOC 2, CBN AML/CFT, and NDPA at the same time — often within the same funding or licensing window. They are usually treated as three separate projects run by three separate teams. They are not separate. They are three expressions of one underlying question: can you prove how your systems behaved?
The cost of compliance is, in practice, the cost of producing that proof. When proof is assembled after the fact — screenshots, exported logs, reconstructed policies — the cost is high and the result is fragile. When proof is emitted by the systems as they run, the cost collapses and the result is defensible.
The single largest lever in readiness is not which framework you start with. It is whether your evidence is native — captured at the source — or reconstructed under deadline. Native evidence serves all three frameworks from one base.
- SOC 2, CBN AML/CFT, and NDPA all reduce to "prove how your systems behaved."
- Treating them as separate projects multiplies evidence cost.
- Source-captured evidence is reusable across all three frameworks.
SOC 2: what it actually requires
SOC 2 is an attestation by a licensed CPA firm that your controls, mapped to the relevant Trust Services Criteria, operated effectively over a period. Security is always in scope; Availability, Confidentiality, Processing Integrity, and Privacy are selected based on your commitments to customers.
A Type I report attests to control design at a point in time. A Type II attests to operating effectiveness over three, six, or twelve months. Enterprise buyers and Series B+ investors ask for Type II. Getting there without an evidence pipeline is expensive; getting there with one is a matter of running your controls and collecting what they emit.
The Trust Services Criteria are defined by the AICPA in the 2017 TSC and the 2022 revised points of focus. They cover security, availability, processing integrity, confidentiality, and privacy as applicable.
- Security is mandatory; the other four criteria are scoped to your commitments.
- Type II (operating effectiveness over time) is what enterprise buyers require.
- Continuous evidence turns Type II from a project into a verification.
CBN AML/CFT: what it actually requires
The CBN regime requires a risk-based AML/CFT programme: customer due diligence, transaction monitoring tuned to Nigerian typologies, sanctions and PEP screening, and timely filings to the NFIU through GoAML. The obligation is continuous — monitoring runs every day, and suspicious transaction reports are expected without delay.
The failure mode is documentation without enforcement. A policy that exists but is not wired into onboarding and monitoring produces no defensible evidence, and examiners test the wiring, not the document.
Obligations derive from the Money Laundering (Prevention and Prohibition) Act 2022, the CBN Anti-Money Laundering and Countering the Financing of Terrorism (AML/CFT) framework, and NFIU guidance on STR/CTR filing via GoAML.
A PSP screens a customer at onboarding but never re-screens. A sanctioned individual is added to a global list six months later. Without periodic re-screening wired to the source, the gap is invisible until an examination — at which point the evidence of "we screen" cannot be produced for the period in question.
- AML is continuous: monitoring and filing do not pause between audits.
- Examiners test enforcement, not the existence of a policy.
- Source-captured screening and monitoring evidence is what survives examination.
NDPA: what it actually requires
The Nigeria Data Protection Act 2023, enforced by the NDPC, requires lawful bases for processing, a Record of Processing Activities (ROPA), DPIAs for high-risk processing, and a working data-subject rights (DSAR) workflow. Controllers of "major importance" — most licensed fintechs — carry the fullest obligations.
A privacy policy on the website is not a control. The NDPC weighs whether requests are actually answered within statutory windows, whether consent is actually recorded, and whether a breach is actually notified.
NDPA 2023 establishes the NDPC as the supervisory authority and imports the core data-protection principles of lawful processing, purpose limitation, and data-subject rights from the global baseline.
- NDPA is enforced by the NDPC; controllers of major importance carry the most.
- A privacy policy is not evidence of compliant processing.
- DSAR handling within statutory windows is the visible test.
Evidence Architecture: the unifying layer
Evidence Architecture is StackWeaver’s three-layer model for turning system operation into audit-ready proof. Engineering and QA produce signals; those signals become Evidence Objects; the Evidence Architecture maps each object to the controls it satisfies across every framework.
Map evidence once. A single access-review record satisfies SOC 2 CC6, ISO 27001 A.9, and (for access to personal data) NDPA. The mapping is the asset; the frameworks are its consumers.
- Evidence Architecture maps one evidence base to many frameworks.
- Engineering and QA signals become reusable Evidence Objects.
- The mapping — not the documents — is what scales.
The familiar sequence
The same evidence layer answers every question a fintech hits as it scales. The sequence is predictable; only the asker changes.
- Investors, enterprises, regulators, and banks all ask for proof.
- One evidence layer answers all four without rework.
- Readiness becomes a standing state, not a per-gate project.
TEMM: measuring maturity
The Trust Engineering Maturity Model measures how continuously you generate evidence — from undocumented to adaptive. Most fintechs start at Level 1–2; continuous readiness lives at Level 4+.
- Maturity is about evidence continuity, not document count.
- Continuous readiness is TEMM Level 4+.
- Take the four-minute assessment to place your level.
Traditional vs Evidence-Native
The structural difference is where evidence comes from. The table compares the two models on the dimensions that change cost and defensibility.
| Dimension | Traditional (reconstructed) | Evidence-Native |
|---|---|---|
| Evidence source | Screenshots & exports, post-hoc | Emitted at the source, continuously |
| Cost over time | Rises before each audit | Falls as controls run |
| Defensibility | Reconstructable incorrectly | Tamper-evident, attributed |
| Framework reuse | Re-collected per framework | Mapped once, reused |
| Time to answer an audit | Weeks | Same day |
- Native evidence is cheaper and more defensible than reconstructed.
- Reuse across frameworks is the compounding return.
- Answer speed is the commercial advantage.
Five questions to test readiness
Before any engagement, these five questions reveal more than a checklist. If the answer to any is "we'd have to pull it together," that is the gap.
- Can you prove, for any day in the last 12 months, who had production access and why?
- Can you show the monitoring alert and its disposition for a flagged transaction?
- Can you evidence every DSAR and its resolution within the statutory window?
- Can you produce the change record behind any production deploy?
- Can an auditor verify all of the above without a meeting?
If question 5 is the only one you can answer "yes" to today, you are further along than most — because it is the one that forces the other four to be true.
Sources
- AICPA — Trust Services Criteria (2017 TSC, 2022 revised points of focus).
- Money Laundering (Prevention and Prohibition) Act 2022 (Nigeria).
- CBN — Anti-Money Laundering and Countering the Financing of Terrorism framework.
- NFIU — STR/CTR filing guidance via GoAML.
- Nigeria Data Protection Act 2023; NDPC supervisory guidance.
- StackWeaver — Evidence Architecture, TEMM, Trust Engineering Operating Model (TEOM).
Can you prove what happened?
Every audit, investor diligence request, enterprise security review, and regulatory inspection eventually converges on the same question. Can you prove what happened? The Playbook is our answer to how you get to "yes" — continuously, and from one evidence layer.
Continue from Research to Implementation
Understanding the regulations is only the first step. The Playbook above explains what SOC 2, CBN AML/CFT, and NDPA require — but a defensible posture is built by implementing trustworthy controls, not by memorising the text. The next step is to turn this research into engineered, evidenced controls that operate continuously.
Below are StackWeaver’s implementation resources — the tools and services that convert the frameworks above into a live evidence layer. Start by exploring the controls, assess your readiness, then implement.
Trust Control Library
Browse engineering and compliance controls mapped to SOC 2, CBN AML/CFT and NDPA. Each control explains why auditors care, what evidence must exist, and typical engineering implementation patterns.
Access Control & Review
CriticalLeast-privilege access enforced in the identity provider, reviewed on a fixed cadence, with every grant and revocation recorded.
CC6.x / A.9 / Req. 7–8
Auditors test whether access is actually restricted and reviewed — not whether a policy exists.
IdP access records, quarterly review sign-offs, role definitions.
Enforce in Okta/Workspace; review via automated access report.
Change Management
CriticalEvery production change is reviewed, approved, and attributed through the pipeline.
CC8.x / A.12 / Req. 6
Demonstrates that uncontrolled change cannot reach production.
Deploy records, PR approvals, pipeline gates.
Require reviewed PRs; block direct main merges.
Encryption at Rest & in Transit
HighEncryption enforced and verified, not assumed.
CC6.x / A.10 / Req. 3–4
A foundational control; gaps are almost always audit findings.
CSP config scans, TLS policy, key-management records.
Enforce via IaC; scan continuously.
Transaction Monitoring
CriticalReal-time monitoring against Nigerian typologies, with alert-to-disposition trails.
CBN AML/CFT
CBN examiners test whether monitoring actually runs and is evidenced.
Monitoring rules, alert logs, disposition records.
Rules engine tuned to local typologies; retained evidence.
KYC / CDD
CriticalIdentity verification (BVN/NIN), tiered CDD, and EDD for high-risk profiles, wired to onboarding.
CBN AML/CFT
The entry control for the entire AML programme.
Verification records, risk ratings, EDD files.
Enforced in onboarding flow; source-captured.
Sanctions & PEP Screening
CriticalReal-time and periodic re-screening against OFAC, UN, EU, and NFIU lists.
CBN AML/CFT
Screening gaps are direct regulatory exposure.
Screening runs, match reviews, disposition.
Integrated screening on onboarding and periodically.
STR / CTR Filing
CriticalDetection thresholds wired to an NFIU/GoAML filing workflow with dual review.
CBN AML/CFT
Late or missing filings carry direct penalties.
Filing records, review sign-offs, submission receipts.
Threshold detection → workflow → tracked submission.
Data-Subject Rights (DSAR)
HighAccess, rectification, erasure, portability, and objection handled within statutory windows.
NDPA
The NDPC weighs timely DSAR handling heavily.
DSAR tickets, response records, timelines.
Workflow with SLA timers and audit trail.
Incident Response
HighA tested runbook; incidents detected, contained, and reported with evidence.
CC7.x / A.16 / Req. 12
Auditors ask for a real, rehearsed process — not a document.
Incident records, post-mortems, comms logs.
Runbook in the repo; game-days quarterly.
Logging & Monitoring
HighCentralised, retained logs proving controls operate over time.
CC7.x / A.12 / Req. 10–11
The backbone of continuous evidence.
Log streams, retention config, monitoring alerts.
Ship to a central store; retain per framework.
Vendor / Third-Party Risk
MediumAssessed, contracted, and monitored vendors with current DPAs.
CC9.x / A.15 / NDPA
Your posture is only as strong as your weakest vendor.
Vendor assessments, DPAs, review dates.
Annual assessment; DPA template enforced.
Awareness & Training
MediumSecurity and AML training with completion records.
CC1.x / A.7 / CBN
A common, easily-fixed finding.
Training records, completion rates.
Automated enrolment; tracked completion.
No controls match your search.
Trust Readiness Roadmap
Organizations rarely become audit-ready in one project. Readiness is achieved progressively — by converting manual evidence into continuously generated evidence, one control at a time, until the posture is live rather than reconstructed.
Discovery
Map your stack, frameworks in scope, and current controls. Classify each as documented or enforced.
Gap Assessment
Score against the relevant frameworks and the TEMM. Produce a prioritised gap report.
Implementation
Convert the highest-risk administrative controls into enforced engineering controls.
Evidence Collection
Route control outputs into a mapped, tamper-evident store so proof accumulates automatically.
Audit Readiness
Surface live posture; hand auditors scoped, read-only access to current evidence.
Continuous Trust
Operate at TEMM Level 4+: evidence generates continuously; readiness is a live state.
What Good Evidence Looks Like
Auditors rarely ask for policies alone; they ask for observable proof that controls actually operated. The examples below are the kinds of artefacts a mature evidence layer produces continuously — not documents assembled under deadline.
Policies
Versioned, owned, and dated — not a binder.
Logs
Centralised, retained, and queryable across systems.
Screenshots
Source-captured configuration evidence, not manual grabs.
CI/CD evidence
Every deploy and gate, attributed and reviewable.
QA evidence
Test runs that verify controls, not just features.
Access reviews
Every grant, review, and revocation with a record.
Security testing
Scans and pen-tests with tracked remediation.
Monitoring
Live signals retained as records, not just alerts.
Vendor assessments
Current DPAs and risk ratings.
Incident reports
Rehearsed runbooks with post-mortems.
Board reporting
Trust posture produced from live data.
Related resources
Practical tools and references that extend this Playbook into action.
Get the Monthly Trust Readiness Brief
When a regulation changes, you hear about it from us first — with the practical implication for your controls, not a press release. No gating, no spam. A short, operator-written brief for compliance and engineering leaders.
Subscribe & book an assessmentWhat this relates to
- Evidence ArchitectureThe three-layer model for how compliance evidence is created, connected, and consumed: Created & Captured → Stored & Connected → Verified & Consumed.
- Evidence-Native SystemsSystems where compliance proof is a property of how they operate — captured at the source — not a document produced under deadline.
- Trust Engineering Maturity Model (TEMM)A six-level model (0–5) measuring how continuously an organisation generates compliance evidence, from Undocumented to Adaptive.
- Trust InfrastructureThe market category StackWeaver operates in: technology able to continuously demonstrate that it can be trusted, not just claim it.
- CBN AML/CFT Compliance for Nigerian FintechsCBN AML/CFT readiness delivered as engineered controls, continuous transaction-monitoring evidence, and NFIU-ready filing workflows — not a policy binder.
- NDPA Compliance for Nigerian Fintechs and Digital BusinessesNigeria Data Protection Act (NDPA) readiness engineered into how your product handles personal data — with continuous evidence the NDPC and your enterprise customers can verify.
- SOC 2 Readiness for African Fintechs and B2B SaaSSOC 2 Type I and Type II readiness delivered as an evidence pipeline — engineered controls that run in production and generate continuous evidence across the audit period.