Three separate requirements sit inside one section
Section 245 of the Companies Act 2016 is usually summarised in a single line: keep company records for seven years, in Malaysia. Read against the Act itself, published by the Companies Commission of Malaysia on its Companies Act 2016 legal framework page, the section is doing several distinct things, and they map onto different controls in Microsoft 365.
Subsection (1) requires accounting and other records sufficient to explain the company's transactions and financial position and to allow proper audit. Subsection (2) requires appropriate entries to be made within sixty days of the completion of the transactions to which they relate. Subsection (3) requires the records to be retained for seven years after the completion of the transactions or operations to which the entries relate. Subsection (4) requires them to be kept at the registered office or at such other place as the directors think fit, open at all times for inspection by the directors.
The location provisions are more layered than the shorthand suggests. Subsection (5) allows accounting and other records of operations outside Malaysia to be kept outside Malaysia, provided such records are sent to and kept at a place in Malaysia and remain available for inspection by the directors at all times. Subsection (7) then gives the Registrar power, where records are kept at a place outside Malaysia, to require the company to produce those records at a place in Malaysia, or to determine the type and manner of the records to be kept in Malaysia. The section also carries a penalty for contravention.
None of that is a determination of any company's position, and this article does not offer one. What it does establish is that a records design has to answer at least three different questions, and that answering only the seven-year one leaves the design incomplete. SCSB's working position is that the statutory reading belongs with the company's own advisers, and that the useful technical contribution is to show which control each requirement lands on.
The retention clock is a transaction date, not a file date
Microsoft's documentation on retention policies and retention labels sets out when a retention period can start. The default is when the content was created. For files in SharePoint, OneDrive and Microsoft 365 Groups locations, the period can instead start when the content was last modified. Retention labels add two further options: when the content was labelled, and when a specified event occurs.
None of the first three is the date section 245 points to. A statutory clock that runs from completion of the transaction is not the same as one running from the date a document was uploaded, and the gap widens for any record created well after the event it evidences. Event-based retention is the mechanism built for exactly this shape, but it only works if something reliably supplies the event date, which is an integration and data-quality question rather than a labelling one.
The last-modified option carries a specific trap. Microsoft notes that every time a file is modified, the start of the retention period is reset, which extends the end of the retention period for that item. Applied to a document that is periodically reopened, that produces a retention period nobody chose. Microsoft's own precedence rules then compound the effect: retention takes precedence over deletion, and the longest retention period wins.
Record, regulatory record, or neither
Microsoft's records management documentation distinguishes three states for a labelled item: a standard retention label, a label that marks the item as a record, and a label that marks it as a regulatory record. The differences are not cosmetic.
A locked record blocks editing contents and blocks deletion, while a container administrator can still change or remove the label. A regulatory record blocks editing contents, blocks editing properties including rename, blocks deletion, blocks moving across containers, and blocks changing or removing the label. Microsoft states the crucial point plainly: after a regulatory record label is applied to content, nobody, not even a global administrator, can remove it.
Regulatory records carry further administrative constraints. The retention period cannot be shortened after the label is saved, only extended. The labels are not supported by auto-labelling policies and must be applied through retention label policies. A regulatory label cannot be applied to a document checked out in SharePoint. Microsoft says that because of the restrictions and irreversible actions, an organisation should make sure it really does need regulatory records before selecting the option, and the option is not available by default and has to be enabled first.
The design decision is therefore about consequences rather than labels. A seven-year statutory minimum does not on its own justify the most restrictive available state. Choosing the irreversible option to express a minimum obligation removes the organisation's ability to correct its own mistake later, and that trade-off deserves to be made deliberately, with legal input, rather than absorbed as a default.
The preservation hold library is a consequence, not a control
Where retention settings apply to SharePoint and OneDrive, Microsoft explains that when a user edits or deletes retained content, a copy is retained in the Preservation Hold library. That library counts towards the site's storage quota, and Microsoft notes that an organisation might need to increase its storage as a result.
This matters for planning rather than compliance. A retention design applied broadly across active sites can grow storage consumption in a way that is invisible until it is not, and the growth is a function of edit and delete activity rather than of the volume of records the organisation actually intended to keep. Scoping the design to the sites and libraries that genuinely hold accounting records, rather than applying it tenant-wide because that is simpler, is usually the more sustainable choice.
Where the data sits, and what Microsoft actually commits to
Microsoft's documentation on Microsoft 365 data locations lists the Local Region Geographies whose tenants can access Advanced Data Residency, and Malaysia is among them. That is a useful fact for any organisation whose records position turns partly on where data sits, and it is one that the general Malaysian commentary and the general product documentation rarely state together.
The detail matters as much as the availability. Microsoft describes Advanced Data Residency as an add-on providing committed data residency for local datacentre regions, available to tenants whose default geography is one of the listed regions and who hold qualifying licences. Coverage is not partial: Microsoft states that customers must cover all eligible paid seats in the tenant with the add-on for the tenant to receive the data residency commitment, that coverage is calculated on purchased rather than assigned seats, and that a tenant holding fewer add-on licences than eligible seats does not have the commitment and is subject to being moved out of the local region. Microsoft also notes that migration is undertaken on a reasonable-efforts basis over a period that can extend to twelve months, and that the in-scope service list is defined, with additional Microsoft Purview services not currently supported.
Pricing sits with Microsoft and is outside the scope of this article. The design point is that data residency here is a licensing and commercial commitment with an ongoing coverage condition, not a setting that is switched on once. Whether any particular residency position satisfies section 245 is a legal question for the company's own advisers and, where relevant, the Registrar.
Decisions to settle before configuring anything
- Which document categories are accounting and other records for section 245 purposes, decided with the company's own advisers, rather than inferred from where files happen to be stored.
- What date each category's retention period should run from, and whether an event date is available reliably enough to support event-based retention rather than a proxy such as created or last modified.
- Whether each category needs a standard retention label, a record, or a regulatory record, with the irreversibility of the last option treated as the deciding factor rather than an incidental setting.
- Which sites and libraries are in scope, and what the resulting Preservation Hold library growth means for storage planning.
- Whether the organisation has a residency requirement at all, and if so whether the add-on coverage condition can realistically be maintained across future licence changes.
- How the position is evidenced if the Registrar exercises the power in subsection (7), and who inside the organisation is accountable for producing records on request.
When outside help may not be needed
An organisation with a single site holding its accounting documents, one retention category, a straightforward seven-year period running from creation, no requirement for irreversible record declaration, and no residency requirement can reasonably configure this directly from Microsoft's documentation. The retention label and policy mechanics are well documented and the configuration is not intrinsically complex.
The work becomes worth scoping properly when the categories multiply, when the retention start date has to come from a business event rather than a file property, when regulatory records are being considered, when several existing retention policies already overlap and their interaction is not understood, or when a residency commitment is in play. The distinguishing factor is not the size of the organisation but how far the requirement has moved away from the defaults.
Separately, retention obligations under company law are not the only clock running. Record-keeping duties under the Income Tax Act 1967 run on their own basis and from their own starting point, and should be confirmed against the Inland Revenue Board of Malaysia's published material rather than assumed to align.
What to do next
Confirm the current text of section 245 and any related guidance directly against the Companies Commission of Malaysia's published material, and obtain professional advice on which records the section captures for the company concerned. Where the requirement is to design and configure retention within Microsoft 365, the Microsoft 365 implementation service can be discussed within an agreed scope.
General-information limitation
This article is general technical information about retention design concepts in Microsoft 365. It is not legal, tax or accounting advice, does not determine which records any company must keep or for how long, and does not confirm that any configuration satisfies section 245 of the Companies Act 2016 or any other requirement. Statutory text and Microsoft product behaviour are set by their respective publishers and change over time. Confirm the current position against the Act and against Microsoft's documentation before implementation, and obtain legal advice on the compliance question itself.
Microsoft, Microsoft 365, Microsoft Purview and SharePoint are trademarks of the Microsoft group of companies.