The OSBR Handbook
Sign in

Legal Compliance

This is the standard for enumerating the legal and regulatory constraints on a project before design begins, and recording them where they will actually be honoured — the project's risk register. It sits at the planning end of the lifecycle, alongside the Development Guide's Planning & Shaping stage: that stage says understand the client's business before you take requirements; this standard says enumerate the legal duties that business carries before you draw the architecture. Legal constraints are design premises, not late surprises. Deviations are allowed, but — as everywhere in the handbook — they must be deliberate and justified in the project's design notes.

Almost every expensive compliance failure is a failure of timing, not of intent: the duty was real and knowable, but nobody looked it up until the architecture was already built around ignoring it. This standard is where OSBR's values become preventative. Be Nice: surfacing a constraint early is a gift to your future teammate — the design that already assumes consent, notation, and retention limits is the one nobody has to tear apart later. Be Kind: these rules exist to protect the people whose personal data and money pass through what we build, so honouring them is a duty owed to those people, not a box-ticking chore. Be Strong: do the unglamorous legal homework up front and tell a client plainly when the law forbids what they asked for, instead of discovering it in an audit or a complaint.

How to read this policy

1. Goal

A cookie banner bolted on after launch, a mandatory online-seller disclosure page — Malaysia's under the Consumer Protection (Electronic Trade Transactions) Regulations 2024, or Japan's 特定商取引法に基づく表記 — scrambled together the week before a store opens, a data flow that turns out to need a telecom-business notification after the pipes are already laid — each is cheap to design in and painful to retrofit. The goal here is to move that work to the one moment it is cheap:

Before design begins, enumerate every legal and regulatory requirement that applies to this project, treat each as a fixed design premise, and record it in the project's risk register so it is owned, tracked, and re-evaluated like any other risk.

The register itself is the legal & regulatory register required by ISO/IEC 27001

Annex A control 5.31 ("Legal, statutory, regulatory and contractual requirements shall be identified, documented and kept up to date") — the same single risk register the project already keeps, not a parallel document that quietly falls out of date.

2. Responsibility

3. Practices

Named, established practice, right-sized for an SME engagement. Import the discipline of the reference material, not its headcount or ceremony.

3-1. Enumerate applicable law from the business facts, before design

You cannot design around constraints you have not listed. Before design begins, the project MUST produce a legal & regulatory enumeration derived from the concrete facts of the engagement (established during the Development Guide's Planning & Shaping stage):

The output is a list of named obligations tied to named business facts — not "we should probably be compliant", but "Malaysian users → PDPA applies → notice and choice, security, and retention limits are design premises; EU users → GDPR adds lawful basis, privacy notice, and data-subject rights".

3-2. The starter checklist — enumerate, then justify each in or out

Every project MUST walk this list and, for each item, record either how it will be satisfied or why it does not apply. An explicit "not applicable, because…" is a required answer, not a silent omission.

Requirement Trigger Named source
Terms of Service Any service users sign up for or transact through Contract law; consumer-protection statutes
Privacy policy / privacy notice Any collection of personal data PDPA Notice and Choice Principle; APPI purpose-of-use notification; GDPR Arts. 13–14
Data-subject / individual rights Processing personal data of Malaysian, Japanese, or EU/EEA users PDPA Access Principle (access, correction, withdrawal, portability); APPI 開示・訂正・利用停止; GDPR Arts. 6, 15–22
Consumer privacy rights (US) Personal data of California (or similar-state) consumers CCPA / CPRA
Online-seller disclosure (Malaysia) Consumer online sales from Malaysia Consumer Protection (Electronic Trade Transactions) Regulations 2024; Electronic Commerce Act 2006
特定商取引法 notation (表記) Consumer online sales from Japan 特定商取引法
Cookie / tracker consent + disclosure Cookies or trackers beyond the strictly necessary ePrivacy Directive 2002/58/EC; Japan external-transmission rules (§3-3)
Telecom-business notification Operating a telecommunications service in Japan 電気通信事業法 (Telecommunications Business Act)
PCI DSS controls Storing, processing, or transmitting cardholder data PCI DSS
Log-retention duties (and limits) Any logging of user activity Retention obligations vs. GDPR storage limitation (§3-5)
DPIA High-risk processing (§3-4) GDPR Art. 35

The checklist is a floor, not a ceiling. It is a prompt to think, not the full universe of law — sector rules (finance, health, education) and other jurisdictions are enumerated the same way.

3-3. Get the Malaysia- and Japan-specific and cookie duties right

These are the ones most often missed by teams anchored on GDPR alone.

3-4. Decide DPIA up front, not after launch

A Data Protection Impact Assessment is required by GDPR Article 35 when processing is likely to result in a high risk to individuals — large-scale profiling, systematic monitoring, or large-scale processing of special-category data are the canonical triggers (see the EDPB / WP29 DPIA guidelines).

3-5. Treat log retention as a two-sided duty

Logs attract two opposing legal pressures, and the design MUST satisfy both:

The resolution is a defined, per-data-class retention period chosen at design time and recorded in the register — long enough to meet retention duties, short enough to meet minimisation duties. "We keep all logs indefinitely" is a design decision that fails both tests and MUST be caught before, not after, the logging pipeline is built. The concrete controls that implement a retention schedule live in Data Protection; this standard is where the duty to have one is fixed.

3-6. Record every requirement in the risk register

Enumeration is worthless if it lives in a one-off document nobody revisits. Each identified legal requirement MUST become an entry — or a linked set of entries — in the project's single risk register, carrying the same fields every entry carries:

Field For a legal requirement
Description The obligation and what triggers it: Malaysian users → PDPA → the seven Personal Data Protection Principles are design premises; EU users → GDPR Art. 25 → data protection by design and by default is required.
Likelihood / Impact The risk of non-compliance — how likely to be caught, how bad the consequence (fine, injunction, reputational, client harm).
Countermeasures The design and process controls that satisfy the obligation (consent flow, notation page, DPIA, retention schedule).
Residual risk (named & accepted) Any remaining exposure, explicitly accepted by an authorised named person — including "we sought counsel and this is the agreed interpretation".
Owner The single named requirement owner.
Re-evaluation date / trigger When it is revisited; and the design changes that force an early revisit.

This makes legal compliance one kind of risk among others, handled by the machinery the project already runs, rather than a separate track. It is the ISO/IEC 27001

control 5.31 legal register and control 5.34 (privacy and protection of PII), made operational.

4. Rules summary (MUST / SHOULD)

5. Re-evaluation triggers

Applicable law is not fixed for the life of a project — the facts that decide it change. A project MUST re-evaluate the affected legal entries, and add new ones, whenever any of the following happens, without waiting for the scheduled date:

References

The authoritative regimes this policy is grounded in.

Compliance- and privacy-by-design (the frame)

Malaysia

Japan

EU / international data protection

Payments

Related OSBR standards