Back
Security Policy

Security Policy

Last updated:

DREWQ processes sensitive personal identity data, including facial photographs read from card chips. This policy describes the security measures we apply to protect that data, how we handle security vulnerabilities, and how we respond to incidents.

1. Security Measures

Data in Transit

  • All communication between clients and the DREWQ API is encrypted using TLS 1.2 or higher
  • Card chip communication uses ICAO 9303 Basic Access Control (BAC) with 3DES Secure Messaging. The chip will not release data without BAC authentication.
  • BAC key material (card number, date of birth, expiry date) is used only during the active card-reading session and is never stored persistently

Data at Rest

  • Sensitive citizen fields — surname, given names, nationality, MRZ lines, and facial photo data — are encrypted individually in the database using AES-256-GCM (authenticated encryption) before storage. Each value uses a unique random nonce. Structural fields required for lookup (personal ID number, card number) remain plaintext.
  • The encryption key is a 256-bit key stored as an environment variable, separate from database credentials, and is never committed to source code or version control
  • Database credentials are managed via environment variables and are never committed to source code or version control
  • API keys are stored in hashed form; plain-text keys are never retained after issuance

Access Control

  • All API endpoints require Bearer token authentication using a valid operator API key
  • Operators can only access citizen records associated with their own account. Cross-operator data access is not possible.
  • API keys can be revoked instantly from the operator dashboard; revoked keys are rejected immediately with no grace period
  • Access logs are retained for a minimum of 12 months for audit and incident investigation purposes

2. Biometric Data Handling

Facial photographs extracted from card chip DG2 are treated as a special category of sensitive data. In addition to general security measures, the following controls apply:

  • Photo data is encrypted at rest using AES-256-GCM as part of field-level encryption applied to all sensitive citizen fields. The raw image bytes are never stored in plaintext in the database.
  • Photo data is stored exclusively for identity verification display purposes. It is not used for automated facial recognition or biometric matching.
  • Access to raw photo data through the API requires a valid operator API key; the data is not exposed in public endpoints
  • Operators are prohibited by our Acceptable Use Policy from using stored photo data for any purpose beyond displaying the card holder's image during verification
  • Photo data is deleted on the same schedule as the associated citizen record. See our Data Retention Policy

3. Vulnerability Disclosure

We operate a responsible disclosure programme. If you discover a security vulnerability in the DREWQ API, platform, or associated infrastructure, we ask that you:

  • Report it to us privately before publicly disclosing it, giving us reasonable time to investigate and remediate
  • Not exploit the vulnerability beyond what is necessary to demonstrate the issue
  • Not access, modify, or delete data belonging to other operators or citizens
  • Not perform denial-of-service testing or automated scanning of our infrastructure

In return, we commit to:

  • Acknowledge receipt of your report within 3 business days
  • Provide a resolution timeline within 10 business days of confirming the issue
  • Not pursue legal action against researchers who act in good faith in accordance with these guidelines
  • Credit you in our release notes if you wish, upon resolution
Report a Vulnerability →

4. Incident Response & Breach Notification

In the event of a confirmed security incident affecting citizen or operator data, we will:

  • Contain and remediate the incident as our immediate priority
  • Notify affected operators within 72 hours of confirming a breach, with details of the data affected, the likely cause, and steps taken
  • Notify the Ghana Data Protection Commission as required under the Data Protection Act 2012 and any applicable regulations
  • Provide a full incident report within 30 days, including a root cause analysis and remediation actions taken

Operators are responsible for notifying their own affected users and regulatory bodies (e.g. the Bank of Ghana for financial institutions) where required by sector-specific regulations.

5. Operator Security Responsibilities

Security is a shared responsibility. Operators must:

  • Secure workstations and card readers from physical and logical unauthorised access
  • Store and transmit API keys securely. Never store them in client-side code, public repositories, or unencrypted configuration files.
  • Rotate API keys immediately upon any suspected compromise and notify us using the contact below
  • Apply operating system and dependency updates to scan station software in a timely manner
  • Restrict access to the operator dashboard to authorised personnel only, using strong authentication

We are not liable for breaches that result from an operator's failure to maintain reasonable security practices on their own systems.

Security contact

For vulnerability reports, suspected breaches, or security questions, use our contact form. We respond within 3 business days.