DEV Community

Cover image for Data Sovereignty as Architecture — How I Built NDPA Compliance Into PRISM's Infrastructure Layer
Victor Okefie
Victor Okefie

Posted on

Data Sovereignty as Architecture — How I Built NDPA Compliance Into PRISM's Infrastructure Layer

The Nigeria Data Protection Act 2023 is not a future concern for Nigerian law firms. It is a present one.
But most of the compliance conversation in the Nigerian legal market has focused on policy — what the Act requires, what firms should tell their clients, what data protection frameworks look like. The infrastructure conversation — what architecture actually makes compliance demonstrable rather than merely asserted — has barely started.
This article is about that second conversation. Specifically, the four architectural decisions I made in PRISM that transform data sovereignty from a policy commitment into a verifiable technical fact.

Why policy is not enough

A privacy policy says: we will not retain your data.
An architecture enforces: we cannot retain your data, even if we wanted to.

The distinction matters enormously in a legal context. A regulator reviewing a firm's compliance posture is not evaluating its intentions. They are evaluating what the system can be made to demonstrate. A policy can be rewritten. An architecture cannot lie.

The NDPA's deletion obligations — specifically the requirement to destroy data in a manner that makes recovery impossible — cannot be satisfied by a delete button that removes a file from the user interface while leaving vector embeddings on the server.

Compliance has to be built into the infrastructure layer. Not added on top of it.

Microsoft Azure — Zero Data Retention by Contract

Standard OpenAI infrastructure processes and retains inference data for safety monitoring purposes. This is documented, reasonable for consumer applications, and architecturally incompatible with a legal document system operating under the NDPA.

Azure OpenAI, Microsoft's enterprise offering, operates under fundamentally different terms. Zero data retention is the default. Content logging is disabled. No query is stored, no inference log is retained, no training exposure occurs.

This is not a PRISM policy. It is Microsoft's contractual commitment — enforceable, auditable, and legally distinct from a terms-of-service assurance.

import { AzureOpenAI } from 'openai';

const client = new AzureOpenAI({
  endpoint: process.env.AZURE_OPENAI_ENDPOINT!,
  apiKey: process.env.AZURE_OPENAI_API_KEY!,
  apiVersion: '2024-08-01-preview',
  deployment: process.env.AZURE_OPENAI_DEPLOYMENT!,
});
Enter fullscreen mode Exit fullscreen mode

The deployment routes inference through enterprise infrastructure with zero retention by default. The API surface is identical to standard OpenAI. What changes is what the infrastructure underneath actually guarantees.

RLS Isolation — Security Enforced Below the Application

Row Level Security is a PostgreSQL feature that enforces data access at the database layer — below the application entirely.

Most systems enforce access control in the application layer. A user authenticates, the application checks permissions, and the query runs. The problem: if the application layer is compromised through a bug, misconfiguration, or session error, the underlying database is a shared resource with no independent protection.

With RLS, the database itself filters every query based on the authenticated user's identity. No application-layer bypass is possible because the restriction is not in the application.

-- Enable RLS on the documents table
ALTER TABLE documents ENABLE ROW LEVEL SECURITY;

-- Users access only their own firm's documents
CREATE POLICY "firm_isolation"
ON documents
FOR ALL
USING (auth.uid() = user_id);

-- Prevent cross-tenant embedding access
CREATE POLICY "embedding_isolation"
ON document_embeddings
FOR ALL
USING (
  document_id IN (
    SELECT id FROM documents WHERE user_id = auth.uid()
  )
);

Enter fullscreen mode Exit fullscreen mode

In PRISM, this makes cross-tenant document access mathematically impossible. Even a hypothetical application bug that attempted to return another firm's documents would receive an empty result from the database. The isolation is enforced where it cannot be bypassed.

The Atomic Purge

A document in PRISM exists across multiple layers: the original PDF, the extracted text chunks, the vector embeddings, and the associated chat history. Standard deletion touches one or two of these layers. The others persist.

_The Atomic Purge executes a single database transaction that destroys all layers simultaneously. Either everything is deleted or nothing is. No partial deletion state is possible.
_

async function atomicPurge(documentId: string, userId: string) {
  const { error } = await supabase.rpc('atomic_document_purge', {
    p_document_id: documentId,
    p_user_id: userId
  });

  if (error) throw new Error(`Purge failed: ${error.message}`);
  return generateDestructionReceipt(documentId, userId);
}
Enter fullscreen mode Exit fullscreen mode

The stored procedure handles deletion across all tables within a single transaction. If any step fails, the entire operation rolls back. Nothing is half-deleted.

The Destruction Receipt

After the purge completes, PRISM generates a Destruction Receipt — a SHA-256 hash of the document content combined with the deletion timestamp, packaged as a verifiable PDF artifact.

async function generateDestructionReceipt(
  documentId: string,
  userId: string
): Promise<DestructionReceipt> {
  const timestamp = new Date().toISOString();
  const hash = crypto
    .createHash('sha256')
    .update(`${documentId}:${userId}:${timestamp}`)
    .digest('hex');

  return {
    documentId,
    deletionTimestamp: timestamp,
    sha256Hash: hash,
    verified: true,
    receiptId: `DR-${hash.substring(0, 16).toUpperCase()}`
  };
}

Enter fullscreen mode Exit fullscreen mode

The receipt is independently verifiable. Given the document ID, user ID, and timestamp, anyone can recompute the hash and confirm the receipt is authentic. This is not a confirmation email. It is an auditable artifact — the difference between asserting deletion and proving it.

The NDPA's requirements for Nigerian law firms are not theoretical. They are active, enforceable, and increasingly examined.

The firms that will navigate regulatory scrutiny with confidence are not the ones with the best privacy policies. They are the ones whose infrastructure makes compliance a verifiable fact rather than an asserted intention.

Architecture cannot lie. Build the compliance into the system before anyone asks for it.

PRISM v1.1 is live at prism-mu-one.vercel.app

Top comments (0)