Introduction: The Singapore Personal Data Protection Act (PDPA)
The Personal Data Protection Act 2012 (PDPA) is Singapore's baseline data protection law. It governs the collection, use, disclosure and care of personal data by organisations, and establishes the Do Not Call (DNC) Registry regime for marketing messages. Administered by the Personal Data Protection Commission (PDPC), which sits within the Infocomm Media Development Authority (IMDA), the PDPA balances the right of individuals to protect their personal data against the legitimate needs of organisations to use data for reasonable purposes. This deep-dive gives CyberSigma clients an auditor-grade view of every obligation, how to scope an assessment, how to build an implementation programme, and how to evidence compliance during a PDPC investigation or a customer-driven data protection audit.
The PDPA has evolved materially since inception. The Personal Data Protection (Amendment) Act 2020 (in force from 1 February 2021) introduced mandatory data breach notification, a new Accountability obligation, expanded consent exceptions (Legitimate Interests and Business Improvement), data portability provisions, and significantly higher financial penalties. Any current assessment must reflect the amended Act, the associated Regulations (including the Personal Data Protection (Notification of Data Breaches) Regulations 2021), and the PDPC's Advisory Guidelines. This guide is written to the amended PDPA as it stands in 2026.
Copyright and source note
This guide is an original CyberSigma work product. The Personal Data Protection Act 2012, its subsidiary Regulations, and the PDPC Advisory Guidelines are Crown/statutory materials published by the Singapore Government and PDPC. We paraphrase and interpret those obligations for practitioner use; we do not reproduce the statutory or guideline text verbatim. Always read this alongside the current Act, Regulations and Advisory Guidelines on the PDPC website, and obtain Singapore-qualified legal advice before relying on any position taken here.
What is the PDPA (SG)?
The PDPA is a principles-based, technology-neutral statute that regulates 'personal data' — data, whether true or not, about an individual who can be identified from that data, or from that data and other information to which the organisation has or is likely to have access. It applies regardless of whether the data is in electronic or physical form. The Act does not prescribe specific security technologies; instead it imposes outcome-based obligations and expects organisations to make reasonable arrangements appropriate to the sensitivity, volume and risk of the data they handle.
The PDPA is structured around two central pillars. The first is the Data Protection Provisions (Parts 3 to 6B of the Act), which set out the obligations organisations owe when handling personal data — consent, purpose, notification, access, correction, accuracy, protection, retention limitation, transfer limitation, accountability, breach notification and data portability. The second is the Do Not Call (DNC) Provisions (Part 9B), which restrict the sending of specified marketing messages (voice calls, text and fax) to Singapore telephone numbers registered on the DNC Registry, and impose sender-identification and consent-checking duties.
Enforcement is investigation-led. The PDPC can require the production of documents, issue directions to stop collecting or to destroy data, and impose financial penalties. Following the 2020 amendments, the maximum financial penalty is the higher of S$1 million or 10% of an organisation's annual turnover in Singapore (for organisations with turnover exceeding S$10 million). Certain egregious acts — such as unauthorised disclosure, improper use, or re-identification of anonymised data by individuals — are now criminal offences carrying fines and imprisonment.
| Attribute | Detail |
|---|
| Full name | Personal Data Protection Act 2012 (as amended by the PDP (Amendment) Act 2020) |
| Regulator | Personal Data Protection Commission (PDPC), under IMDA |
| Region | Singapore |
| In force | Data Protection provisions from 2 July 2014; amendments from 1 Feb 2021 onwards |
| Scope | Personal data of individuals, in electronic or non-electronic form |
| Model | Principles/outcome-based; technology-neutral |
| Max financial penalty | Higher of S$1m or 10% of annual Singapore turnover (>S$10m turnover) |
| Breach notification | Mandatory to PDPC and affected individuals for notifiable breaches |
Who must comply?
The PDPA applies to all private-sector 'organisations' that collect, use or disclose personal data in Singapore, whether or not the organisation is formed or resident in Singapore and whether or not the personal data or activities are located there. 'Organisation' is defined broadly to include individuals, companies, associations and bodies of persons, corporate or unincorporated. The Act uses two operative roles that mirror the controller/processor distinction: the organisation (accountable for the data) and the data intermediary (a party that processes personal data on behalf of, and for the purposes of, another organisation under a written contract).
- Private companies, partnerships and sole proprietors operating in Singapore or handling data of individuals in Singapore.
- Foreign organisations that collect, use or disclose personal data in Singapore (extra-territorial reach), including cloud and SaaS providers serving Singapore customers.
- Data intermediaries (processors) — subject to the Protection and Retention Limitation obligations and breach notification duties in respect of data processed on behalf of another organisation.
- Charities, clubs, societies and non-profit associations acting as organisations.
- Marketing senders and telemarketers subject to the Do Not Call provisions when sending messages to Singapore numbers.
| Actor / scenario | PDPA applicability |
|---|
| Singapore-incorporated company | Full Data Protection and DNC obligations |
| Overseas SaaS serving SG customers | Applies to collection/use/disclosure of SG individuals' data |
| Data intermediary (processor) | Protection, Retention Limitation and breach-notification duties; other obligations flow to the principal organisation |
| Public agency (Government body) | Excluded from PDPA; governed instead by the Public Sector (Governance) Act and internal IM instructions |
| Individual acting personally/domestically | Excluded when acting in a personal or domestic capacity |
| Employee acting for their employer | Excluded personally; obligations rest with the employer organisation |
| Business contact information (BCI) | Consent/notification/purpose obligations do not apply to BCI used for business purposes |
Public sector carve-out
Public agencies and organisations acting on behalf of public agencies are not subject to the PDPA. Their handling of personal data is governed by the Public Sector (Governance) Act 2018 and Government instruction manuals. Private organisations must not assume equivalence — a private vendor to Government is still bound by the PDPA for its own collections.
Structure of the PDPA (SG)
The PDPA is best assessed as a set of eleven Data Protection obligations plus the Do Not Call regime. The PDPC's own Advisory Guidelines on Key Concepts group the substantive duties into named 'obligations'. The table below maps each obligation to its statutory anchor and the practical control question it raises. Use these as the top-level domains for any PDPA assessment — every requirement in the master checklist rolls up to one of these.
| Domain / obligation | Statutory anchor (Act) | Core control question |
|---|
| Consent | Sections 13-17 | Do we obtain, and can we evidence, valid consent (or a lawful exception)? |
| Purpose Limitation | Section 18 | Do we only collect/use/disclose for purposes a reasonable person considers appropriate and that were notified? |
| Notification | Section 20 | Do we inform individuals of purposes on/before collection? |
| Access | Sections 21, 21A | Can individuals obtain their personal data and disclosure history? |
| Correction | Section 22 | Can individuals have inaccurate data corrected and corrections propagated? |
| Accuracy | Section 23 | Do we make reasonable effort to ensure data is accurate and complete? |
| Protection | Section 24 | Do we make reasonable security arrangements to protect data? |
| Retention Limitation | Section 25 | Do we cease retention/anonymise when purpose and legal need ends? |
| Transfer Limitation | Section 26 | Do overseas transfers meet comparable-protection standards? |
| Accountability (incl. DPO, policies) | Sections 11, 12 | Do we appoint a DPO, have policies, and demonstrate governance? |
| Data Breach Notification | Sections 26A-26E | Do we assess, notify PDPC and individuals of notifiable breaches? |
| Data Portability | Sections 26F-26J | Can we transmit data to another organisation on request (once in force)? |
| Do Not Call (DNC) | Part 9B (ss.36-48) | Do we check the DNC Registry and identify senders for marketing messages? |
Master assessment checklist
This is the core of the assessment. Each obligation below is expanded into concrete verification points and the typical evidence an auditor would request. Do not skip any group — a PDPC investigation or a mature third-party audit will test each one. Where an obligation has statutory sub-provisions (for example the consent exceptions, or breach assessment criteria), they are called out explicitly.
1. Consent (ss.13-17)
An organisation may collect, use or disclose personal data only with consent, unless an exception applies. Consent must be for purposes that have been notified, must not be a condition of providing a product/service beyond what is reasonable, and must not be obtained through false or misleading information or deceptive practices. Deemed consent, deemed consent by contractual necessity, deemed consent by notification, Legitimate Interests and Business Improvement exceptions must each be documented where relied upon.
| What to verify | Typical evidence |
|---|
| Consent is obtained before or at collection and tied to notified purposes | Consent capture screens, timestamps, opt-in logs |
| Failure of consent conditions (bundling / forced consent) is avoided | Product terms review, consent-not-a-condition analysis |
| Deemed consent scenarios are identified and documented | Deemed-consent register, contractual-necessity notes |
| Reliance on Legitimate Interests exception is risk-assessed | Legitimate Interests Assessment (LIA) records |
| Reliance on Business Improvement exception is scoped and documented | Business Improvement purpose documentation |
| Withdrawal of consent is honoured and downstream effects communicated | Withdrawal request logs, cessation confirmations |
| Consent for minors follows PDPC guidance on capacity | Age-gating logic, parental consent records |
2. Purpose Limitation (s.18)
| What to verify | Typical evidence |
|---|
| Purposes are limited to what a reasonable person considers appropriate | Purpose register mapped to processing activities |
| Data is not used/disclosed beyond notified or reasonable purposes | Data flow maps, RoPA, use-case sign-offs |
| New/secondary purposes trigger fresh notification or consent | Change-control records for new purposes |
3. Notification (s.20)
| What to verify | Typical evidence |
|---|
| Purposes are notified on or before collection | Privacy notices, just-in-time notices, forms |
| Notices are clear, accessible and specific to the collection context | Published privacy policy, layered notices |
| Where deemed consent by notification is used, the notice is proper | Notification records and opt-out windows |
4. Access (ss.21, 21A)
| What to verify | Typical evidence |
|---|
| Access requests are logged, verified and answered within reasonable time | Access request register, response templates |
| Disclosure history (to whom, within a year) can be provided | Disclosure-tracking logs |
| Statutory exceptions to access are applied and documented | Exception decision records, legal sign-off |
| Reasonable fees, if charged, are disclosed in advance | Fee schedule, applicant communications |
5. Correction (s.22)
| What to verify | Typical evidence |
|---|
| Correction requests are actioned and, where refused, reasons recorded | Correction request register |
| Corrections are propagated to third parties who received the data | Downstream correction notifications |
| Where correction is disputed, an annotation is made | Annotation/notation records |
6. Accuracy (s.23)
| What to verify | Typical evidence |
|---|
| Reasonable effort is made to ensure accuracy where data is used to make a decision affecting the individual or is disclosed | Data validation rules, source-of-truth policy |
| Data quality checks exist at capture and update points | Validation logs, de-duplication reports |
7. Protection (s.24)
The Protection obligation is the most security-heavy. Organisations must make reasonable security arrangements to prevent unauthorised access, collection, use, disclosure, copying, modification, disposal or similar risks. This is where CyberSigma's technical controls assessment concentrates, mapping to administrative, physical and technical measures.
| What to verify | Typical evidence |
|---|
| Administrative controls: security policy, roles, training, NDAs | Policy set, training records, signed NDAs |
| Access control on a need-to-know / least-privilege basis | RBAC matrix, access reviews, joiner-mover-leaver logs |
| Encryption of data at rest and in transit for sensitive data | Encryption standards, TLS/cert config, key management |
| Network security, patching and endpoint protection | Patch reports, EDR coverage, firewall rules |
| Logging, monitoring and alerting on data access | SIEM configuration, audit trails, alert runbooks |
| Physical security for premises, media and paper records | Access badge logs, clean-desk policy, disposal records |
| Secure disposal / destruction of media and documents | Certificates of destruction, wiping records |
| Data intermediary security is contractually mandated and verified | Processor contracts, security schedules, audit rights |
| Vulnerability management and penetration testing | VA/PT reports, remediation tracker |
8. Retention Limitation (s.25)
| What to verify | Typical evidence |
|---|
| A retention schedule maps data categories to retention periods and legal basis | Data retention policy and schedule |
| Data is destroyed or anonymised when purpose and legal need cease | Deletion logs, anonymisation records |
| Backups and archives are covered by retention rules | Backup retention config, archive purge logs |
9. Transfer Limitation (s.26 & Regulations)
| What to verify | Typical evidence |
|---|
| Overseas transfers are inventoried with destination countries | Transfer register / data map |
| Comparable protection is ensured via contract, BCR, certification (e.g. APEC CBPR/PRP) or specified exceptions | Data transfer agreements, model clauses, certifications |
| Cloud and sub-processor locations are identified and covered | Sub-processor list, hosting-region documentation |
10. Accountability, DPO and Policies (ss.11-12)
| What to verify | Typical evidence |
|---|
| A Data Protection Officer (DPO) is designated and contactable | DPO appointment letter, published DPO contact |
| Internal data protection policies and practices are documented | Policy suite, procedures, DPMP |
| Staff are trained and complaints/queries are handled | Training completion, complaints handling procedure |
| Data Protection Impact Assessments (DPIA) are conducted for higher-risk processing | DPIA templates and completed assessments |
| A record of processing (data inventory / RoPA) is maintained | Data inventory / RoPA |
11. Data Breach Notification (ss.26A-26E)
A breach is notifiable if it results in, or is likely to result in, significant harm to affected individuals, or is of significant scale (affecting 500 or more individuals). Notifiable breaches must be reported to the PDPC as soon as practicable and in any case within 3 calendar days of assessing it as notifiable, and affected individuals must be notified where required.
| What to verify | Typical evidence |
|---|
| An incident response and breach assessment procedure exists | IR plan, breach assessment methodology |
| Breach assessment against significant-harm and 500-individual thresholds | Breach assessment records, decision logs |
| PDPC notification within 3 days of notifiable determination | Submitted PDPC notification, timeline log |
| Affected individuals notified where required, with mitigation advice | Individual notification templates and dispatch logs |
| Data intermediaries notify the principal organisation without undue delay | Processor notification clauses and records |
| Post-incident review and remediation tracked | PIR reports, remediation tracker |
12. Data Portability (ss.26F-26J)
| What to verify | Typical evidence |
|---|
| Portability requests can be received and validated (once provisions commence) | Portability request procedure |
| Applicable data can be transmitted to a receiving organisation in a machine-readable form | Export tooling, data format specification |
| Exclusions (derived/opinion/third-party data) are correctly applied | Data classification for portability |
13. Do Not Call Registry (Part 9B, ss.36-48)
| What to verify | Typical evidence |
|---|
| DNC Registry is checked before sending specified marketing messages | DNC check logs and confirmation IDs |
| Valid confirmation of clear/dirty status is retained for the required period | Retained DNC confirmations (60-day validity records) |
| Messages identify the sender and provide contact details | Message templates with sender ID and contact info |
| Calling-line identity is not concealed for voice calls | Telephony configuration evidence |
| Ongoing-relationship exemption is documented where relied upon | Consent records and relationship evidence |
Scoping the assessment
Accurate scoping prevents both under-assessment (missing regulated processing) and wasted effort. PDPA scope is defined by the personal data an organisation handles and the activities performed on it, not by a network boundary. Begin by inventorying every business process that touches personal data of individuals in Singapore, then map the systems, third parties and locations involved.
- Identify all personal data categories held: customer, employee (note employment-context nuances), marketing, vendor-contact, CCTV, biometric and any special categories such as health or financial data.
- Map business processes and data flows end-to-end, including collection channels (web, app, call centre, paper), storage, internal use and disclosures.
- Enumerate data intermediaries (processors) and sub-processors, including cloud, payroll, CRM, analytics and outsourced call centres.
- Determine overseas transfer destinations and hosting regions for each system.
- Distinguish personal data from Business Contact Information (BCI), which is largely exempt from Consent/Notification/Purpose obligations when used for business purposes.
- Identify marketing channels subject to the Do Not Call provisions (voice, SMS, fax to Singapore numbers).
- Flag high-risk processing (large-scale, sensitive data, profiling, new technology) that warrants a DPIA.
Scope boundary tip
Employee personal data is in scope for most PDPA obligations, but there are specific consent exceptions for managing or terminating an employment relationship. Treat HR data as in-scope and document the exceptions relied upon rather than excluding it wholesale.
Implementation approach (phased)
CyberSigma delivers PDPA readiness as a structured programme. Each phase has defined activities and tangible deliverables so progress is auditable and leadership can track maturity growth.
Phase 1 — Governance and discovery
- Activities: appoint/confirm the DPO, establish a data protection steering group, run data discovery and build the data inventory (RoPA), and map data flows and third parties.
- Deliverables: DPO appointment, RoPA/data inventory, data flow diagrams, third-party (intermediary) register, initial scope statement.
Phase 2 — Gap assessment
- Activities: assess each of the eleven obligations plus DNC against current state; run technical controls review for the Protection obligation; assess overseas transfers and retention.
- Deliverables: gap assessment report with risk-rated findings, prioritised remediation roadmap, DPIA for high-risk processing.
Phase 3 — Policy and control build
- Activities: draft/refresh the Data Protection Management Programme (DPMP), privacy notices, consent mechanisms, retention schedule, transfer agreements, and access/correction procedures; implement or harden security controls.
- Deliverables: DPMP, policy suite, standard notices and consent flows, retention schedule, data transfer agreements, updated processor contracts.
Phase 4 — Operationalisation
- Activities: deploy access/correction request handling, breach response runbook, DNC checking process, DPO query mailbox; deliver staff and role-based training.
- Deliverables: request-handling workflow, incident/breach runbook with 3-day clock, DNC procedure, training records.
Phase 5 — Assurance and continual improvement
- Activities: internal audit against the checklist, tabletop breach exercise, management review, and metrics reporting; align with PDPC's Data Protection Trustmark (DPTM) certification where desired.
- Deliverables: internal audit report, tabletop findings, KPI dashboard, management review minutes, DPTM readiness pack.
Maturity / capability model
CyberSigma scores each PDPA obligation on a five-level capability scale. This gives leadership a defensible, comparable view of readiness and a target operating maturity, and aligns with the accountability expectations underpinning the DPTM.
| Level | Name | Description |
|---|
| 0 | Absent | No policy, owner or control; obligation not addressed |
| 1 | Initial | Ad hoc, reactive handling; no documentation or ownership |
| 2 | Developing | Basic policies drafted; inconsistent application; partial evidence |
| 3 | Defined | Documented, owned and operating across the organisation with records |
| 4 | Managed | Measured with KPIs, periodically reviewed and audited |
| 5 | Optimised | Continually improved, automated where possible, embedded by design |
Assessment and audit approach
- Confirm scope: agree the entities, processes, systems, data categories and geographies in scope, and the obligations to be tested.
- Kick-off and information request: issue the evidence request list and schedule interviews with the DPO, IT, HR, marketing and legal.
- Data mapping validation: verify the RoPA/data inventory and data flow diagrams against reality through walkthroughs.
- Control testing: test each obligation's controls using inquiry, inspection and re-performance; sample access/correction requests and consent records.
- Technical review: assess Protection-obligation controls (access control, encryption, logging, patching, disposal) and review VA/PT results.
- Third-party review: examine intermediary contracts, transfer safeguards and sub-processor coverage.
- Breach-readiness test: walk through the breach assessment and 3-day notification workflow, ideally via a tabletop.
- Gap analysis and risk rating: rate each finding by likelihood and impact against PDPA exposure.
- Reporting: deliver findings, root causes, and a prioritised remediation roadmap with owners and dates.
- Re-assessment: verify remediation and update the maturity scores; advise on DPTM certification if in scope.
Evidence request list
The following categorised evidence set supports a full PDPA assessment. Provide current, dated versions and be prepared to demonstrate live systems during walkthroughs.
- Governance: DPO appointment, org chart, data protection steering minutes, DPMP.
- Policies: data protection policy, retention schedule, breach/incident response plan, acceptable use, disposal policy.
- Data mapping: RoPA/data inventory, data flow diagrams, systems inventory.
- Consent and notice: privacy notices, consent capture screens/logs, deemed-consent and LIA records.
- Individual rights: access and correction request registers, response templates, disclosure logs.
- Protection controls: access control matrix, access review records, encryption/key management standards, patch and EDR reports, SIEM/log samples, physical security logs, destruction certificates.
- Third parties: intermediary and sub-processor register, processor contracts and security schedules, audit reports.
- Transfers: overseas transfer register, data transfer agreements, certifications (APEC CBPR/PRP), hosting-region documentation.
- Retention and disposal: deletion/anonymisation logs, backup retention configuration.
- Breach management: past breach assessments, PDPC notifications, individual notifications, PIR reports.
- DNC: DNC check logs and confirmations, marketing message templates with sender identification.
- Training and awareness: training material, completion records, phishing-simulation results.
Roles and responsibilities
| Role | PDPA responsibilities |
|---|
| Board / Senior Management | Own accountability, approve the DPMP, provide resources, review risk |
| Data Protection Officer (DPO) | Ensure compliance, act as PDPC/individual contact, oversee policies, advise on DPIAs |
| IT / Security | Implement Protection-obligation controls, logging, encryption, breach detection |
| HR | Manage employee data, apply employment consent exceptions, deliver training |
| Marketing | Operate consent and DNC checks, ensure sender identification |
| Legal / Compliance | Advise on obligations, draft contracts and transfer agreements, manage enforcement |
| Business / Process owners | Maintain accurate RoPA entries, honour purpose limitation, action requests |
| Data Intermediaries | Protect data, observe retention limits, notify principal of breaches |
KPIs to track
- Percentage of processing activities recorded in the RoPA / data inventory.
- Access and correction requests closed within target time (%).
- Mean time to assess and notify a breach (target within the 3-day statutory window).
- Percentage of staff completing annual data protection training.
- Number of overdue remediation items from the gap assessment.
- Percentage of data intermediary contracts with compliant security and breach clauses.
- Percentage of systems covered by the retention schedule and automated purge.
- DNC check compliance rate for outbound marketing campaigns.
- Number of DPIAs completed for high-risk processing versus identified.
- Encryption coverage of sensitive personal data at rest and in transit (%).
Readiness checklist
- A DPO is appointed and their contact details are published.
- A Data Protection Management Programme (DPMP) and policy suite are approved and current.
- A complete RoPA / data inventory and data flow maps exist and are maintained.
- Consent, notification and purpose practices are documented with evidence.
- Access and correction request procedures operate within reasonable timelines.
- Reasonable security arrangements protect personal data (access, encryption, logging, disposal).
- A retention schedule is enforced with deletion/anonymisation records.
- Overseas transfers are inventoried and covered by comparable-protection safeguards.
- A breach response plan enforces the 3-day PDPC notification clock and individual notification.
- Data intermediary contracts include protection, retention and breach-notification clauses.
- DNC Registry checks and sender identification are in place for marketing.
- Staff receive role-appropriate data protection training and it is recorded.
- DPIAs are completed for higher-risk processing.
- Internal audit / management review of PDPA compliance occurs periodically.
Common gaps
- No DPO formally appointed, or the DPO role is nominal with no authority or resources.
- Incomplete or stale data inventory, so unknown processing and shadow systems escape controls.
- Consent relied upon informally with no records, or forced/bundled consent that breaches s.14.
- No breach assessment methodology, causing failure to notify PDPC within the 3-day window.
- Data intermediary contracts lacking protection, retention or breach-notification clauses.
- Overseas transfers with no comparable-protection safeguards or hidden sub-processor regions.
- No retention schedule, leading to indefinite retention and increased breach exposure.
- Weak Protection controls: shared accounts, no encryption of sensitive data, poor log retention.
- Marketing sent without DNC checks or sender identification, risking Part 9B penalties.
- No DPIA process for new products, profiling or AI-driven processing.
- Privacy notices that are generic and do not reflect actual purposes or collection contexts.
- Access/correction requests handled ad hoc with no register or timeline discipline.
PDPA (SG) mapped to other frameworks
Organisations subject to multiple regimes can reuse controls. The mapping below is indicative — obligations are analogous, not identical — and should guide, not replace, a control-by-control cross-walk.
| PDPA (SG) obligation | GDPR (EU) | ISO/IEC 27701 | NIST Privacy Framework |
|---|
| Consent | Art. 6-7 lawful basis / consent | Consent management (7.2/7.3) | CT.PO / Control-Consent |
| Notification | Art. 13-14 transparency | Notice to data subjects (7.3.2) | Communicate-P |
| Access & Correction | Art. 15-16 rights | PII principal requests (7.3.6-7.3.9) | Control-P (individual participation) |
| Protection | Art. 32 security | Annex A/B security controls; ISO 27001 | Protect-P |
| Retention Limitation | Art. 5(1)(e) storage limitation | Retention & disposal (7.4.7) | Control-P (data lifecycle) |
| Transfer Limitation | Art. 44-49 transfers | International transfers (7.5) | Govern-P / Control-P |
| Accountability / DPO | Art. 5(2), 24, 37-39 | Governance & DPO role (6.x) | Govern-P |
| Breach Notification | Art. 33-34 breach notification | Incident management | Detect / respond functions |
| Data Portability | Art. 20 portability | PII principal requests | Control-P |
| Do Not Call | ePrivacy / marketing rules | N/A (marketing-specific) | N/A |
How CyberSigma helps
Partner with CyberSigma for PDPA readiness
CyberSigma combines CERT-In empanelled and PCI QSA expertise with hands-on Singapore data-protection practice to take your organisation from discovery to defensible compliance. We build your RoPA and data flow maps, run a full gap assessment against all eleven obligations plus the DNC regime, harden your Protection-obligation controls with technical testing, draft your DPMP, notices, retention schedule and transfer agreements, and stand up a breach-response capability that meets the 3-day PDPC clock. We then support internal audit, tabletop exercises, and — where you want external assurance — readiness for the PDPC Data Protection Trustmark (DPTM). Talk to CyberSigma to turn PDPA obligations into an operating advantage.
