How to Build a Data Privacy Programme for a Small or Mid-Size Company

What does a data privacy programme actually include?

A privacy programme is a set of habits and records that let a company handle personal data lawfully and prove it. A policy on its own is not a programme, as the first customer data request or supplier questionnaire quickly shows.

Strip away the clause numbers and the major laws (the EU and UK GDPR, India's Digital Personal Data Protection Act 2023, California's CCPA as amended by the CPRA, Singapore's PDPA, Nigeria's NDPA, Australia's Privacy Act and others) converge on the same ideas. Collect data for a stated purpose. Keep only what that purpose needs. Tell people plainly what you do. Keep it accurate. Delete it when the purpose ends. Protect it in proportion to the harm a leak would cause. And be able to show all of this with records, not promises.

Around those principles sit four practical duties: a lawful reason for each use, a way for people to exercise their rights, written contracts with the companies that process data for you, and a plan for telling the regulator and affected people when something goes wrong. A working programme turns each of those into a routine with an owner and a date.

Which privacy laws apply to my company?

Three things usually pull a company into a privacy law: where it is established, where the people whose data it processes are located, and its sector. A software firm in Lagos with customers in the UK sits inside Nigeria's law because of where it is and may also be inside the UK GDPR because it offers services to people in the UK. A clinic, a bank or a school adds sector rules on top. In the United States there is no single federal privacy law, so state laws such as California's apply above thresholds of revenue or consumer numbers.

You do not need to decide this alone, and you should not. Write a half-page scoping note with the facts: where you operate, where your customers, employees and vendors are, what kinds of data you hold, your sector and rough volumes. Send it to counsel and ask for a short written view. Then record the answer in one place and set your deadlines from it, because every later process (rights requests, breach notification, retention) depends on knowing which rules you are working to.

Laws are also moving, in India, California, the UK and elsewhere. Keep a dated note of what applies and review it at least twice a year.

How do you map the personal data your company holds?

Interview people rather than sending a survey. A survey gets you what people remember; thirty minutes with the owner of each system gets you what they actually do. Ask six questions: what personal data the system holds, whose and roughly how many, why you have it, where it comes from and where it goes, who can see it, and how long it is kept. Flag sensitive data, children's data and anything leaving the country.

Start with the obvious owners (HR, sales, support, finance, marketing, IT), then send a short all-staff note asking where else personal data hides: exports on laptops, chat groups, old tools nobody cancelled, an agency's shared drive.

Each interview becomes one or more rows in a data inventory: system, owner, data subjects, data categories, sensitivity, purpose, lawful basis, source, vendor, storage location. Rearranged by purpose, the same information becomes your record of processing activities, the document most regulators expect you to be able to produce. Keep it alive by re-interviewing an owner whenever a system changes.

How do you choose a lawful basis, and when do you need consent?

GDPR-style laws list six lawful bases: consent, contract, legal obligation, legitimate interests, vital interests and public task. India's DPDP Act centres on consent plus a list of legitimate uses, and California's model relies on notice and the right to opt out of sale or sharing. The common principle is simple: for each purpose, be able to say why you are allowed to do it, and tell people.

A quick decision rule works for most small companies. If the processing is needed to deliver what the person asked for, the usual basis is contract. If a law requires it, legal obligation. If it is marketing to non-customers, non-essential cookies or sharing data with partners for their own use, consent. If it is something people would reasonably expect and does not override their interests, legitimate interests where your law recognises it, backed by a written balancing test. Sensitive data needs an extra condition on top.

Consent is often the wrong default. It can be withdrawn at any moment, it is invalid if people cannot refuse and still get the service, and you must be able to show who agreed to what and when. Where it is right, use an unticked box, specific wording, a stored record and an easy withdrawal route.

How should you handle data subject access and deletion requests?

A frequent failure is not refusing a request but not noticing it. A request can arrive by any channel in any words, and under most laws the clock starts when it is received. Under the GDPR, for example, the European Data Protection Board's guidance for small businesses says a controller must respond within one month, extendable by two further months for complex requests, with the person told about any extension inside the first month.

Set up a privacy mailbox, tell every employee to forward any request about someone's data the same day, and log each request with a calculated due date. Verify identity by asking for one detail you already hold rather than a passport. Search every system on your data map, including email and chat, and remove other people's data before you send anything.

Deletion is rarely total. You may delete an account, marketing profile and support tickets, yet have to keep invoices for tax law and a small suppression record so you never market to that person again. Say so in plain words: what you deleted, what you kept, why, and how to complain to you and to the regulator.

How do you manage vendors, processors and international transfers?

When another company processes personal data on your instructions (a payroll bureau, a cloud CRM, a marketing agency, an AI tool), you usually remain responsible for what it does. That is why most laws expect three things before data flows: due diligence, a written contract with privacy terms, and a check on where the data goes.

Send a short questionnaire in plain words: what data they hold, where it is stored, which sub-processors they use, how they secure it, how fast they report incidents and whether they train AI models on your data. Score the answers and record the vendor on a register with a review date.

Compare the vendor's data processing agreement against a checklist rather than redrafting it: processing only on your instructions, confidentiality, security, notice of sub-processors, help with rights requests, breach notice within a stated time, deletion or return at the end, audit rights and transfer terms. When data leaves the country, record the mechanism (an adequacy decision, standard contractual clauses or another route your law allows) and have counsel confirm it. Pausing a vendor that will not sign is a legitimate decision.

When do you need a privacy impact assessment?

Privacy by design, an idea credited to Ann Cavoukian's work as Ontario's Information and Privacy Commissioner, means building privacy into a project from the first sketch. In a small company the practical form is a five-minute screen for every new project, tool or campaign that touches personal data.

Ask whether the project involves sensitive data, children, new technology or AI, large-scale or systematic monitoring, profiling or automated decisions with real effects, combining data sources, or a new vendor or cross-border flow. Rate likelihood and impact for the people affected. Low-risk projects are recorded and go ahead. High-risk ones, and anything combining AI with monitoring or involving sensitive or children's data, get a full data protection impact assessment: the purpose and necessity, the data flows, the risks to people, the measures that reduce them, and a named sign-off for any residual risk.

Employee monitoring deserves particular care: consent is weak at work, so monitoring needs a clear purpose, the least intrusive option, a plain notice and a retention limit. Check your HR team and local law.

What should you do in the first 72 hours of a data breach?

Breaches are expensive. IBM's Cost of a Data Breach Report 2026 puts the global average cost of a breach at USD 4.99 million, a 12% increase on the previous year. A small company will rarely face that figure, but the cost of a confused response is real at any size.

Write and print the plan before you need it: roles and contacts, including counsel's out-of-hours number. Then work in phases. In the first hour, report, contain (revoke the link, disable the account, isolate the device) and preserve evidence. In the next few hours, establish the facts: what data, whose, how many people, whether it was sensitive, encrypted, accessed or copied. Within the first day, score the severity and decide with counsel whether to notify the regulator and the people affected. Many laws use a 72-hour window for the regulator, but some expect an immediate first report and others count from assessment, so set your deadline from your own law.

Record your reasons whether you notify or not, and review a decision not to notify whenever new facts arrive. Afterwards, look for the process gap, never the person who reported.

Where does AI fit into privacy compliance?

AI touches the programme in two directions. First, AI tools your company uses on personal data are systems like any other: add them to the inventory and ask whether the vendor trains on your data, how long prompts are kept, whether the tool decides anything about a person without human review, whether you can test it for accuracy and bias, and whether people know AI is involved. A machine recommends; a human decides.

Second, AI can help you run the programme: turning interview notes into inventory rows, classifying data fields, drafting notices and response letters in plain words, planning a search across systems, comparing a vendor contract against a checklist, or brainstorming risks for an assessment. Replace names with labels before you paste anything in, check every legal statement against your dated notes or counsel, and edit the output rather than forwarding it. Whether a law applies, which basis is right, whether to refuse a request and whether a breach is notifiable remain human decisions.

If you want a fast way to check your own judgement on these calls, the Personal Data Judgment assessment from AssessAll tests how you read typical privacy situations. A Jobulary development plan can then turn the gaps into specific skills to practise over the next quarter.

How can a small company build the programme in 90 days?

Split the work into three phases. Days 1 to 30 are scope and discovery: charter signed, laws decided with counsel, the privacy mailbox and staff reporting rules live, every system mapped with an owner, rights request logging running and a breach plan printed. Days 31 to 60 are decisions: a lawful basis for each purpose, consent records fixed, notices published, a retention schedule adopted, vendor questionnaires out and the first deletion run done. Days 61 to 90 are controls: every vendor contracted or paused, the project screen built into procurement and project briefs, staff trained, a tabletop drill run and a self-audit scored and reported to leadership.

Report a handful of numbers each month: requests answered on time, vendors without a contract, systems with no lawful basis, overdue deletion runs and training completion. Bodhih Training's Data Privacy Compliance Starter kit packages this method with a programme workbook, a breach helper, forms, templates and a 90-day calendar.