If your software processes personal data originating from Ghana, you almost certainly have to register with Ghana's Data Protection Commission. Section 27(1) of the Data Protection Act, 2012 (Act 843) makes registration mandatory, not optional, and it applies to data controllers and data processors alike — including foreign companies with no Ghanaian office. A controller must register within 20 days of commencement of business, and renew every two years.
That is the answer most founders are looking for. The rest of this article is about the part nobody warns you about: registration asks you to describe your system, and most teams cannot describe their system without a week of reconstructing it by hand. This is engineering context, not legal advice — confirm your own position with Ghanaian-qualified counsel.
What registration actually asks for
Registration requires a form carrying the controller's details plus information about the type, processes and purpose of the data to be collected and processed.
Read that phrase as an engineer rather than as a lawyer. It describes a data inventory — a record of processing: what personal data you hold, where it flows, and why you hold it.
Most product teams cannot produce one on demand. They can produce a schema dump, which is not the same thing — a schema tells you a column exists, not why it exists or whether anyone still needs it. The gap between users.phone_number VARCHAR(20) and "collected at signup for transaction OTP delivery, retained for the life of the account, shared with one SMS aggregator" is the entire exercise, and it is normally closed by three engineers with a whiteboard, once a year, badly.
The alternative is to make the inventory a property of the codebase:
- Annotate personal-data columns at the source — a comment convention, a decorator, a tag in your migration files. Pick one, enforce it in review, and make an unannotated new column fail lint.
- Record a purpose per field, not per table. One table routinely carries fields collected for different reasons, with different lifetimes.
- Record the third parties each field reaches. Error trackers in particular quietly receive personal data inside stack-trace payloads and almost never appear on anyone's inventory.
- Generate the document. An inventory derived from annotations is current on every deploy; a spreadsheet is stale by the second sprint.
None of that is required by Act 843. Act 843 requires that you can answer the question — and a generated answer stays true where a hand-written one does not.
Twenty days is a project-plan item, not a launch checklist item
A data controller who controls processing of personal data originating from Ghana must register within 20 days of commencement of business. Most teams put compliance tasks in the pre-launch column, between "set up status page" and "write the privacy policy". That sequencing does not survive a clock tied to commencement of business rather than to your launch date. If your Ghanaian entity starts operating while the product is still in build, the clock has started and the product is not finished.
So put the inventory work in the same sprint as the schema work, when the answers are cheap. A field's purpose is obvious the week someone adds it and archaeological eighteen months later. That is why we schedule it at data-model design rather than launch readiness when planning app development work in Ghana.
Foreign companies serving Ghanaian users are in scope
The jurisdictional hook in Act 843 is data originating from Ghana. It is not "companies incorporated in Ghana" and not "servers located in Ghana". Foreign companies are among the entities the Commission lists as required to register. If you are a non-Ghanaian SaaS with Ghanaian users, that is a question to answer rather than assume away, and two things follow for the build.
You need to know which users are Ghanaian, and you probably do not. Plenty of products store country only as a billing-address string, or infer it from an IP at request time and never persist it. If your obligations turn on the origin of the data, origin has to be a durable, queryable attribute of the record, set at collection rather than re-derived later from a GeoIP lookup that has since drifted.
"We only process it on behalf of our customer" does not remove you. The duty reaches processors as well as controllers. It does change what you describe on the form, which is reason enough to write down, per data flow, which role you occupy.
Ghana and Nigeria diverge here in ways that matter to anyone building for West Africa generally. Nigeria's regime — see our guide to NDPR-compliant software — has its own registration and audit structure, and a single "West Africa compliance" work item treating the two as one obligation will be wrong in both countries.
Purpose, retention, export and deletion are schema decisions
Once you have described your processing to a regulator, the description is something you have to keep true. Four things stop being policy documents and start being columns.
Purpose. Reusing a field for something other than what it was registered for is a product decision with a compliance dimension. Storing purpose beside the data makes that visible at code review instead of at audit.
Retention. "How long do you keep it" has no answer in most systems, because nothing ever deletes. A retention clock needs a per-record timestamp to count from and a job that actually runs. Retrofitting that onto a schema with no collection timestamps and cascading foreign keys pointing the wrong way is a migration, not a ticket.
Export. Producing everything you hold about one person stays a query when identity is centralised, and becomes a project when it is spread across nine tables, a logging pipeline, a warehouse and three vendors.
Deletion. Hard delete versus soft delete versus anonymisation is a design decision with audit-trail constraints pulling against it. Fintech teams feel this hardest, since transaction records carry retention duties of their own — a tension we go into in our notes on building fintech software in Ghana.
The penalty, and the two-year clock
Processing personal data without registering is a criminal offence under Act 843, carrying a fine of up to 250 penalty units or imprisonment. We are deliberately not converting that into cedis: the value of a penalty unit is set separately by legislative instrument and changes, so any figure quoted in an article ages badly. Check it at source rather than trusting a number in a blog post, this one included.
Registration must be renewed every two years — a calendar obligation, and two-year obligations are the ones organisations reliably miss, being long enough that whoever did it last time has changed roles or left. Put the renewal somewhere that survives staff turnover: a named owner, a deputy, and a ticket created on the day you register with a due date two years out. "Someone will remember" is not a control.
What this changes
Concrete actions, in the order we would do them:
1. Determine whether the origin hook catches you. Do you process personal data originating from Ghana? If you cannot answer from your database, that is the first finding.
2. Make country of origin a stored, queryable field, set at collection rather than inferred at read time.
3. Annotate personal-data fields with purpose, retention period and downstream recipients — enforced in code review, not in a wiki page.
4. Generate the inventory from those annotations, so the document you would file is derived from the system rather than from memory.
5. Schedule registration inside the build sprint. Twenty days from commencement of business will not wait for your launch date.
6. Build export and deletion paths while the schema is young, including the vendors holding copies.
7. Assign the two-year renewal to a named owner with a deputy, ticket created the day you register.
8. Read the Commission's own guidance — it published Guidelines to Demonstrate Data Protection Compliance, dated July 2025 on its site. Read the primary source rather than anyone's summary of it.
We do not have Ghanaian clients and are not holding ourselves out as authorities on Ghanaian law. What we do have is a pattern that repeats across jurisdictions: the registration form is easy and the inventory behind it is not, and teams that treat that inventory as a document rather than a build artefact end up writing it twice.
Verify your own position with Ghanaian-qualified counsel. This post is engineering context, not legal advice.