Public Compliance Resource

Audit Request Templates and Process Overview

How Dootsa handles regulator, election-body, enterprise, and external code audit requests without exposing unnecessary operational detail.

Election body intake template

Submit the following to your Dootsa compliance contact:

Requester name, organisation, and verified email
Legal basis (statute, contract, or regulatory authority)
Jurisdiction (e.g. ZA)
Request type: election_body, regulator, code_auditor, or enterprise
Purpose and specific review objective
Requested artifact types (see evidence pack below)
Review time window for log extracts
Access tier: Tier 1 evidence bundle (default) or Tier 2 read-only repo (dual approval required)

External code auditor ROE (summary)

Tier 1 (default)

Access: Signed evidence grant with commit manifest, selected modules, RLS audit output

Approval: Compliance reviewer approval

Tier 2 (exception)

Access: Time-boxed read-only repository access

Approval: Dual approval: legal/compliance + engineering lead

Prohibited: production database access, secrets, forking the repository, sharing code with unauthorised third parties. Full process documented in repository: docs/compliance/external-code-audit-process.md

Evidence pack contents

election_governance_summary — civic/election control mapping
control_matrix — POPIA and ISO alignment
rls_audit_report — tenant isolation evidence
source_code_review_pack — commit manifest and control-to-code index
control_evidence_index — SOC 2 TSC mapping
architecture_overview — disclosure scope and components
audit_logs — redacted operational logs (scoped window)
dpia_summary, key_management_policy, incident_response_playbook
pen_test_summary — when available

Delivery: time-limited signed grant after legal review, redaction, and integrity packaging.

Regulator communication template

Dootsa acknowledges your audit request under [legal basis]. We will confirm scope within 5 business days and release approved artifacts per agreed SLA. Evidence is delivered through encrypted, time-boxed access grants. Raw respondent-identifying data is withheld unless explicitly approved and legally required.

Escalation: compliance contact on file · Incident findings reported through coordinated disclosure.

Public-safe security disclosure

Role separation, immutable evidence chains, data minimisation, policy-driven redaction, and expiring access grants. Public posture API: /api/public/compliance/posture

What we intentionally do not publish

Private identifiers, secret keys, internal credential paths, privileged infrastructure maps, and any detail that would weaken participant security.

For trust positioning, visit Trust and Compliance · For business context, visit Dootsa for Businesses.