Tech platform public affairs in Singapore is hardest in the weeks when several regulatory tracks land at once: a data breach notification clock, a falsehood direction, an online-harm notice, a code obligation and a consultation that closes on Friday. More statements won't fix that. What works is a narrative stack. Keep one fact spine that everyone draws from. Add a thin layer for each regulator that only counsel-cleared owners can touch. Put the audience layers on top: they can simplify what sits underneath, but they can't contradict it.
This guide is for heads of public policy, government relations and corporate communications at platforms, marketplaces and apps with Singapore users, and for the advisers who support them. It is process guidance, not legal advice. We link the primary rules, and your counsel decides how they apply to you.
If you first need to know which agency does what, start with our Singapore regulator map for communicators. If you run brand pages or community spaces, our piece on Online Safety Act compliance communications for brand admins covers the administrator side. This article covers what happens when those tracks overlap in the same five working days.
Why multi-regulator weeks break platform communications
Each regulatory track arrives with its own clock, its own vocabulary and its own internal owner. The data protection officer is counting days, trust and safety is processing a notice, the policy team is polishing a consultation response, and the communications team is fielding journalists. Every workstream drafts its own account of events because that is quicker than waiting for anyone else. By Thursday there are four versions of what happened, each almost right.
Outside the building, nobody sees separate tracks. Users, reporters, MPs and officials see one company, and they compare what it said on Monday with what it said on Wednesday. A line written for one regulator can be screenshotted and read next to a line written for another.
The law doesn't let one process wait for another, either. Under section 26D(9) of the Personal Data Protection Act 2012, the duties to notify the Personal Data Protection Commission and affected individuals apply concurrently with any obligation under other written law to notify any other person, including a public agency. When you have several clocks, you work them in parallel, so your facts have to hold up in parallel too.
The tracks that can land in the same week
Not every platform faces every track. The table lists the ones that most often overlap for a Singapore-facing tech platform, with the obligation worth knowing before the week starts. Check each against the live source before you brief.
| Track | Who acts | What it means for communications | Primary source |
|---|---|---|---|
| Notifiable data breach | Personal Data Protection Commission (PDPC), an agency under MDDI | Once you assess a breach as notifiable, notify the PDPC as soon as practicable and no later than 3 calendar days after the day of that assessment; affected individuals are notified on or after that, subject to the Act's exceptions | PDPA s26D |
| Online falsehoods | POFMA Office, situated within IMDA, which issues Directions on the instruction of Ministers | A Correction Direction sets the form, manner, place and time of a correction notice, and can be issued even if the person did not know the statement was false | POFMA s11; POFMA Office |
| Online Safety Code for designated social media services | IMDA, under the Broadcasting Act | In force since 18 July 2023; designated services submit annual online safety reports to IMDA for publication | IMDA Code, para 25 |
| Online Safety Code for app distribution services | IMDA, under the Broadcasting Act | In force since 31 March 2025 for designated app stores, including age assurance requirements | IMDA Code |
| Online harms | Online Safety Commission (OSC), operating since 29 June 2026 under the Online Safety (Relief and Accountability) Act 2025 | Directions can go to the poster, the administrator of a group or page, or the platform, and non-compliance is a criminal offence; platforms must take reasonable steps once properly notified, and prescribed platforms have specified response periods | MDDI release; MinLaw release |
| Public consultations | The ministry or agency running it, listed on REACH | Your filed submission becomes the benchmark your public posts are measured against | REACH consultations |
| Parliament | MPs and office-holders | The Order Paper lists the agenda for each sitting and goes online a day before it, so a live issue can surface with little notice | Order Paper |
Two details matter for planning. First, under POFMA section 11(4) a Correction Direction can be issued even to someone who did not know the statement was false, so treat your own official channels and spokespeople as possible recipients, not just anonymous accounts. Second, MDDI has said six online service providers are prescribed with additional obligations for the purposes of the OSC, and that platforms prescribed for the statutory torts must address harm within specified time periods once notified. If you are on either list, your response times are set by the rules, not by your communications plan.
The narrative stack: five layers, one direction of travel
A narrative stack is a small set of linked documents with a strict hierarchy. Facts flow upward. If a public line turns out to be wrong, you correct the fact spine first and then rewrite everything that depends on it. Nobody patches the top layer on their own.
Layer 1: the fact spine
What happened, what you know, what you don't know yet, what you have done, and when, with timestamps. Version it (v1, v2, v3) and record the time of each change. Owner: the incident lead, with counsel. Rule: every other layer cites a spine version, and nothing appears anywhere else that isn't in the spine.
Layer 2: the regulator files
One short file per open track, written in that regulator's own terms: notifiable data breach, correction notice, Online Harm Notice, code obligation. Owner: counsel, supported by government relations. Rule: a regulator file can omit facts but never adds new ones, and nothing in it goes public until counsel clears it.
Layer 3: the policy position
What you think about the underlying policy, such as your view on a code or your consultation submission. Owner: the head of public policy. Rule: keep "we are complying" separate from "here is what we think of the rule". Never argue policy inside a compliance response, and never let a compliance week quietly rewrite a policy position you have already filed.
Layer 4: the public layer
Users, media, partners and investors. Owner: the communications lead. Rule: it can simplify the layers below but never contradict them. If a correction notice must be carried in a specified form, it is carried exactly as specified. Don't predict what any regulator will do next.
Layer 5: the internal layer
Employees, moderators, customer support and sales. Owner: internal communications, with operations. Rule: front-line staff get the public layer, a short "do not say" list and an escalation path. Moderators get their operational instructions separately, so procedural detail never leaks into a customer reply.
The multi-regulator week matrix
This matrix is the working page of the stack. Print it, fill it in on the first day and update it at every sync. The "do not say" column is where most of the avoidable damage gets prevented.
| Track | Depends on spine item | Lead owner | Public line allowed? | Do not say | Sync point |
|---|---|---|---|---|---|
| PDPC notification | Time of the notifiable-breach assessment; scope of affected data | Data protection officer and counsel | Only as counsel clears, in step with notifying individuals | "No personal data was affected" before the assessment supports it | Daily, first thing |
| POFMA direction (if one is issued to you) | The specific statement named in the direction | Counsel and communications lead | Carry the correction notice as specified | Commentary that relitigates the facts around the notice on official channels | On receipt, then at each compliance step |
| OSC direction or Online Harm Notice | Which content, which location, what action was taken and when | Trust and safety, with counsel | Usually no comment on individual cases | Anything that identifies a victim or describes the harmful content | On receipt and on completion |
| IMDA code duties | What your published reports and policies already say | Head of public policy | Only what is already public | Previews of metrics or claims of regulatory approval | Weekly |
| Consultation submission | Positions consistent with this week's facts | Head of public policy | A summary after filing, consistent with the submission | "Our view" posts before the filing is final | Before filing |
| Parliamentary attention | The current spine version | Government relations | Factual information only | Guesses about what a minister will say | When the Order Paper is published |
A five-day run sheet with owners and timing
Name one stack editor on the first day. This is a senior communications or government relations person with direct access to counsel. The editor isn't counsel and doesn't make legal calls. The job is making sure every layer cites the latest spine version.
| Day | Task | Owner | Done when |
|---|---|---|---|
| 1 | Open one shared room and name the stack editor; freeze non-essential posting; agree a holding line | Stack editor | Holding line approved; scheduled posts paused |
| 1 | Write spine v1 and put every open clock on one timeline with its start time | Incident lead and counsel | Each track's start time and deadline is written down |
| 2 | Draft regulator files from the spine; counsel reviews | Counsel and government relations | Each file cites a spine version |
| 2 | Brief front-line staff with the public layer and the "do not say" list | Internal communications | Support scripts updated |
| 3 | Check each regulator file against the latest spine before any submission | Stack editor | No file cites an outdated version |
| 3–4 | Release public updates only in step with cleared notifications | Communications lead | Public, regulator and internal versions match |
| 4 | Check the policy layer: consultation drafts, briefing notes, any parliamentary material | Head of public policy | No contradiction with this week's compliance posture |
| 5 | Retrospective: which phrases changed, why, and who changed them; archive all versions | Stack editor | Version log filed with counsel |
Adjust the days to your actual clocks. If an assessment is made on Monday, a 3-calendar-day notification window ends on Thursday, so the Day 3 check has to happen before then.
Worked example: one week, four tracks (hypothetical)
This example is fictional and simplified. It shows how the stack works, not how any real case was handled.
A regional marketplace app with a sizeable Singapore user base finishes its internal assessment on a Monday morning: a breach of its customer database is notifiable. The PDPC clock is now running. On Tuesday, a viral post claims the company "sold" user data to advertisers. That's false. The first instinct in the room is a loud rebuttal on every channel.
The stack slows that down. The rebuttal uses only what spine v2 says: what was accessed, what wasn't, and what the company has done. It says nothing about whether the Government will act on the false post, because that decision belongs to the Government. If a correction notice later appears on that post, the company's channels point to it and don't repeat the original claim.
On Wednesday, an Online Harm Notice arrives. A user says another user is doxxing them on the app's community forum, using details that may have come from the breach. Trust and safety takes it under the platform's duties, and counsel adds a line to spine v3 on whether the two issues are linked. The public layer says nothing about the individual case.
On Thursday, the policy team gets ready to file a consultation response drafted a month earlier. The stack editor flags a sentence calling notification duties "unnecessarily burdensome". The policy view can stay, but the timing and tone now read badly next to an open breach. The team rewrites it as a constructive proposal before the Friday close.
Without the stack, the company would have published three figures for affected users, argued with a falsehood in the same thread as its apology, and filed a consultation response that undercut its own crisis posture. With it, there is one set of facts across four tracks and a version log counsel can stand behind.
Who this is for, and who can skip it
| Use this if you… | Skip or adapt it if you… |
|---|---|
| Run public policy, GR or communications for a platform, marketplace or app with Singapore users | Have one product, one regulator and no user-generated content; one crisis plan is enough |
| Routinely field more than one regulator in the same quarter | Need a ruling on whether a duty applies to you; that is counsel's call |
| Support a platform as an agency or adviser and need a shared working page | Are building the agency map from scratch; read the regulator map first |
Mistakes that turn one hard week into three
- Letting each workstream write its own facts. Four almost-right versions are worse than one incomplete version.
- Turning compliance into advocacy. A notification or correction is not the place to argue that the rule is wrong.
- Arguing with a correction in the same channel. It keeps the original claim in circulation and puts you at odds with the direction.
- Announcing regulatory outcomes. "The regulator has cleared us" is rarely yours to say.
- Forgetting that employees post. Brief staff before the story peaks, not after a personal post becomes the story.
- Importing a global statement. A group statement drafted for another market can name the wrong obligations, or none at all.
Decision framework: do you need a stack editor this week?
- 1. Are two or more regulatory tracks open at once? If not, your usual issues process is probably enough.
- 2. Does any track have a statutory clock of a week or less? If yes, put it on the timeline today.
- 3. Is more than one person speaking for the company? If yes, a stack editor stops the drift.
- 4. Is a consultation submission or parliamentary briefing due within the month? If yes, add the policy layer check.
If you answered yes to two or more, appoint a stack editor before the next sync.
FAQ
Is a narrative stack required by Singapore law?
No. Nothing requires a document with that name. It is a working method that helps you meet several real obligations at once without contradicting yourself.
Who should be the stack editor: counsel or communications?
Usually a senior communications or government relations lead who works closely with counsel. Counsel owns the legal judgement. The editor owns consistency across the layers.
Does the Online Safety Commission only deal with large platforms?
No. MDDI says directions can go to the person who posted the content, the administrator of the group or page, or the platform. Some platforms are prescribed with extra obligations, but administrators and posters are also covered.
Should we comment on an open consultation while a regulatory issue is live?
Generally only after you file, and only in terms consistent with the submission. If the live issue changes how a filed position reads, ask the agency's published channel whether you can update it, rather than revising it in public.
What to do next
Pick the next likely overlap: an annual report cycle, a consultation window, a product launch next to a known compliance date. Build the spine template and the matrix for it now, while nothing is on fire. If you want help setting up the stack or running it in a live week, see Singapore government relations, Singapore public affairs or crisis and issues communications for Singapore, or contact us.