BLE Tracking and PDPA in Singapore: A Compliance Guide for Indoor Asset Tracking

If you’re a Singapore operations or compliance officer evaluating BLE tracking, the question you don’t want to ask late is: “Is this PDPA-compliant?” The default answer — “yes, when scoped correctly” — sounds reassuring but isn’t useful. What you actually need is a list of decisions to make before deployment so that the deployment doesn’t end up being non-compliant.

This guide unpacks the Personal Data Protection Act 2012 (PDPA) and the PDPC’s 2021 guidance on location data as they apply to indoor BLE tracking specifically — both for asset-only deployments (the common case) and personnel-tracking deployments (the regulated case). It concludes with the contractual clauses your SaaS vendor should provide.

The short version

Scenario	PDPA scope	Consent needed	Retention limit	Notes
BLE on assets only (tools, totes, equipment)	Outside PDPA scope	No	Determined by operational need (no PDPA ceiling)	Standard asset tracking — most Singapore deployments
BLE on staff for asset check-in/out (workflow coupling)	Borderline — pseudonymised ID usually fine	Usually not, if no personal data exposed to other functions	Determined by operational need	Confirm with DPO; pseudonymise where possible
BLE on staff for safety / lone-worker	In PDPA scope	Yes	Up to operational need; 30–90 days is conservative norm	Publish notice; provide opt-out where feasible
BLE on visitors	In PDPA scope	Yes — must opt-in or be necessary under contract	7–30 days, then delete	Hospital visitor tracking, event tracking
BLE on customers in retail	In PDPA scope (location data)	Yes — explicit opt-in	7–30 days	Specific PDPC retail-location-data guidance applies

The above is a quick-reference. The remainder of the article explains each row with citations to PDPC guidance and what your SaaS contract should look like.

What is PDPA and PDPC, in one paragraph

The Personal Data Protection Act 2012 is Singapore’s omnibus data-protection law, administered by the Personal Data Protection Commission (PDPC). It covers all “personal data” — data, whether true or not, about an individual who can be identified from that data or that data and other information. PDPA obligations apply to any organisation that collects, uses, or discloses personal data in Singapore, with limited exceptions (public agencies, employees acting in the course of employment, etc.).

What counts as “personal data” for BLE tracking depends entirely on what the BLE beacon is attached to. Attach it to a laptop → not personal data (the laptop is corporate property). Attach it to a person → the beacon’s identity trail can become personal data the moment it links to a person’s name.

Asset-only deployments: outside PDPA scope

The most common Singapore BLE tracking use case is asset tracking: BLE beacons attached to tools, totes, equipment, laptops, machines. The beacon broadcasts an ID; the gateway records position over time.

In this scenario, the beacon ID has no link to a natural person. It’s a corporate asset identifier. PDPA does not apply — there is no “personal data” being collected, used, or disclosed.

What you still need to handle (but not for PDPA reasons):

• Cybersecurity — protect the gateway network from intrusion
• Access control — limit dashboard access to authorised operators
• Data retention — decide when to delete historical location trails (operational decision, not PDPA-mandated)
• Cross-border data transfer — most Singapore SaaS deployments keep data in Singapore anyway; confirm with the vendor

The Intensecomp BLE Tracking SaaS Singapore plan defaults to asset-only deployments with Singapore data residency, and PDPA scope doesn’t apply.

Personnel-tracking deployments: in PDPA scope, requires consent

The moment you attach a BLE beacon to a person (staff badge, lone-worker safety fob, hospital staff tag), the beacon ID — even if pseudonymised — becomes a piece of data that, when linked to a name, constitutes “personal data” under PDPA.

Per the PDPC’s 2021 Advisory Guidelines on the Use of Location Data, organisations must:

1. Publish a clear consent notice explaining what data is being collected, for what purpose, by whom, and for how long.
2. Obtain consent before tracking begins. For employees, consent can be opt-in (preferred) or opt-out in narrow cases — but in any case, employees must be able to opt out of tracking that’s not strictly necessary for their employment.
3. Limit retention to “the minimum necessary” to fulfil the stated purpose. PDPC has not specified a numeric ceiling, but typical Singapore deployments cap at 30–90 days for staff safety tracking and 7–30 days for visitor tracking.
4. Provide access and correction mechanisms — staff must be able to ask “where was I tracked on day X” and get an answer.
5. Notify PDPC of breaches within 72 hours for significant breaches, 30 days for others (per the 2021 amendments).

For hospital staff safety tags (a common BLE SaaS use case), PDPC has historically accepted 30-day retention as conservative. For visitor tracking, 7 days is standard.

What your SaaS contract should contain

If your BLE deployment involves any personnel tracking — or might in the future — your SaaS contract must include specific contractual clauses. Here is the checklist we recommend:

Data-processing terms

• Vendor is a “data intermediary” on your behalf, not a “data controller”
• Vendor processes personal data only on your documented instructions
• Vendor protects personal data with reasonable security arrangements
• Vendor notifies you of any personal-data breach within 24 hours of detection
• Vendor complies with your audit rights for personal-data processing

Data residency and cross-border transfer

• Personal data stays in Singapore by default
• Any cross-border transfer requires your written approval
• Vendor lists all sub-processors and notifies of changes
• Vendor commits to Singapore-based support staff for personal-data operations

Retention and deletion

• Configurable data-retention period per asset / per staff tag
• Default 30–90 days for personnel; longer for assets
• Automated deletion at end of retention period
• Manual “right to be forgotten” workflow for staff deletion requests

Access control and audit log

• Role-based access control on the dashboard
• SAML / SSO support for enterprise customers
• Immutable audit log of all personal-data access (who viewed what location)
• Quarterly access-review report delivered to your DPO

For the Intensecomp BLE Tracking SaaS Singapore contract, all of the above are included as standard. We’ve shipped this contract template to customers across healthcare, BFSI, and government-adjacent industries without modification.

Compliance with other frameworks

If you operate in a regulated Singapore industry, expect additional frameworks:

• Healthcare (PDPA + healthcare-specific) — additional data-handling for clinical data; SaaS contract should reference compliance with the MOH Healthcare Cybersecurity Toolkit and any applicable GxP guidance.
• Banking and financial services — the Monetary Authority of Singapore (MAS) Notice 658 on cyber hygiene applies to technology risk management; vendor should be able to demonstrate alignment.
• Government-linked corporations — additional data-classification requirements; vendor should support data-classification tagging.
• Multi-national corporations — be aware of GDPR overlap. If your company is EU-based or processes EU personal data, GDPR’s stricter rules apply on top of PDPA; the more-strict framework (GDPR) governs.

A good SaaS vendor will ask about your industry before quoting — a great SaaS vendor will help you model the compliance implications of your specific tracking workflow.

Practical implementation checklist

Before you sign a SaaS contract, walk through this checklist:

1. Map every category of asset that will get a BLE beacon. For each category, confirm whether it links to a person or not.
2. For personnel-tracking categories, draft a consent notice. PDPC has templates.
3. Define retention per category. Put it in the SaaS contract.
4. Confirm data residency. “Singapore only” is the safest baseline.
5. Confirm breach notification timing. Vendor should commit to 24-hour detection-to-notification.
6. Walk the dashboard with your DPO before signing. DPO should sign off on access controls and audit logging.
7. Document the deployment workflow — who sees location data, when, and why. Put it in your internal data-protection policy.

If your BLE deployment is asset-only and stays in Singapore, you should be able to deploy in 4–6 weeks from PO. If it involves personnel data or cross-border considerations, budget 8–12 weeks for the additional compliance work.

Common mistakes

We’ve seen these pitfalls across dozens of Singapore deployments:

1. Assuming “GDPR-compliant” means “PDPA-compliant”. GDPR is stricter; PDPA has additional carve-outs. Different frameworks, different rules.

2. Skipping consent notice for staff safety tags. “It’s for safety, they wouldn’t object” is not a defence. Publish the notice and obtain opt-in where possible.

3. Storing location data indefinitely. No operational reason to keep 18 months of historical beacons. Cap retention at 90 days for personnel.

4. Sharing dashboard access broadly. Only authorised operators should see personnel locations. Asset-only visibility can be broader.

5. No DPO sign-off before deployment. Bring the DPO into the project from day one. They’ve seen these issues before.

6. Offshoring the support team. Vendor support staff in another country can mean cross-border data transfers you didn’t authorise. Keep support in Singapore.

Next steps

• For the full SaaS delivery model and PDPA-aligned contract template, see BLE Tracking SaaS Singapore.
• For the legal landscape overview, refer to the PDPC website and the IMDA IoT Cyber Security Guide.
• For industry-specific compliance (healthcare, BFSI, government), contact our compliance team for a 30-minute consult.

Frequently asked questions

Is BLE tracking on personal devices (phones) covered differently than BLE on dedicated tags?

Yes — phone-based BLE tracking typically uses apps and pulls location data with full user consent (think: Find My iPhone). Dedicated BLE tags without an app component typically fall under beacon-only tracking, which may or may not be PDPA-scope depending on use case. Discuss your specific architecture with your DPO.

If a BLE beacon is on a tool that John uses, is that personal data about John?

PDPC’s position: the beacon ID is the device’s, not John’s. The location trail is the tool’s location trail. It becomes personal data about John only if you can link the beacon ID to John’s identity (e.g., by cross-referencing against a check-out log that maps “John borrowed tool #4471 today”). If you keep beacon data anonymous and don’t cross-link, you stay outside PDPA scope.

What’s the maximum retention period under PDPA?

There is no numeric maximum. PDPA requires retention “as long as necessary for the purpose”. For personnel tracking, 30–90 days is conservative and aligns with PDPC guidance. For asset-only data, retention is an operational decision.

Does the SaaS vendor need their own PDPA-compliant contract?

If the vendor processes personal data on your behalf, yes — they need a Data Processing Agreement (DPA) compliant with PDPA Section 4(2). Most Singapore SaaS vendors have a template DPA they can share.

What about location data on a corporate phone given to an employee?

Personal-data collection of an employee’s location via a corporate phone falls under the employment exception for PDPA — collection in the course of employment is exempt, provided it’s for legitimate purposes and proportionate. But this exemption is narrow; for safety-grade tracking (lone-worker), many Singapore employers opt to obtain written consent anyway for clarity.

What if my vendor is hosted in another country?

Then you’re doing a cross-border data transfer. PDPA requires reasonable steps to ensure the recipient is bound by comparable obligations. For SaaS deployments, the safest approach: confirm vendor’s data residency is Singapore, and any cross-border transfer requires your written approval in the DPA.

What about MAS Notice 658 (Banking)?

If you’re a bank or financial services provider in Singapore, additional cyber-risk controls from MAS Notice 658 apply. Vendor should be able to demonstrate alignment. The Intensecomp BLE SaaS contract template includes MAS-aligned security commitments for BFSI customers.

Can I deploy without involving the DPO?

You can, but you shouldn’t. The DPO’s sign-off before deployment is the single best risk mitigation available to your operations team.

---

Deploying BLE tracking in Singapore and need a PDPA-aligned SaaS contract template? Book a consult with our compliance team — we’ll walk through the data-processing addendum and retention rules against your specific deployment.