A privacy policy is not a data map and does not prove that every collection, use and vendor transfer is lawful.
Privacy lead with business owners
Quarterly and at product change
Create a system-level data inventory.
Data inventory and flow diagram.
The Digital Personal Data Protection framework applies through notified provisions and rules. Startups should check commencement dates before assuming that every obligation is simultaneously live.
Map each data field from collection to deletion: person, purpose, source, system, access, vendor, location, retention and security. Include employee, candidate, customer, user, vendor and website data.
Notices and consent should reflect the real product. Pre-ticked boxes, bundled unrelated purposes and inaccessible withdrawal routes create risk. Processing may also rely on other grounds permitted by law, which should be documented.
| Control | What it covers | Operating rule |
|---|---|---|
| Collection | Field, person and source are identified. | Collect only what the product needs. |
| Purpose | Business and legal purpose is recorded. | Avoid silent reuse. |
| Sharing | Processors and third parties are mapped. | Use contracts and access limits. |
| Retention | Deletion or legal retention rule is assigned. | Test actual system deletion. |
Prioritise high-volume, sensitive and externally shared data. Build controls into product design and procurement rather than fixing notices after launch.
Maintain a commencement tracker for the Act and Rules. The company should distinguish controls already legally effective from prudent controls implemented in advance.
Document the decision, owner, due date and evidence expected. A verbal explanation should be converted into a board note, approved working, contract amendment, portal acknowledgement or reconciliation before the item is treated as closed.
Rules, forms, thresholds and interpretations can change. The operating team should use the latest official source and the actual company facts instead of copying a control from another entity or prior year.
Ask four questions: Is the obligation or accounting treatment applicable? Has the underlying transaction been completely recorded? Does the evidence agree with the books and portal? Has an independent reviewer challenged the exception?
The review should distinguish a timing difference from an error, a judgement from a missing document, and a control failure from a one-time operational delay. Repeated small exceptions deserve root-cause action because they often become material during audit, fundraising, notice or distress.
The operating record should connect the control stages—collection, purpose, sharing, retention—to the same transaction population. If the source list, accounting ledger, tax return, board record and management dashboard use different populations, the review can appear complete while exceptions remain outside the test.
Management should define an exception threshold, but the threshold must not hide repeated failures. A small error occurring every month can signal weak master data, unclear ownership or a broken interface. The reviewer should record root cause, immediate correction and preventive action separately.
Closure requires evidence. At minimum, the file should show who prepared the work, who reviewed it, which source documents were used, what differences remained and when the next follow-up is due. Screenshots without context or spreadsheets without source references are not a durable control record.
Map the actual data and money flows rather than relying on contract labels. Systems, vendors, user screens and bank accounts should agree with the legal role allocated in the contract; a platform cannot avoid regulatory responsibility through marketing terminology.
Incident and complaint data should feed the control review. Repeated consent withdrawals, failed settlements, customer complaints or access exceptions are evidence that the designed process is not operating as intended.