What do governance, risk and compliance each mean?

Governance is how your organisation makes and enforces decisions. Risk is what could go wrong and what you are doing about it. Compliance is proving to outsiders that you meet the obligations they impose. Three different jobs. They share the same raw material, though, which is why software treats them as one category.

Governance

The decision layer. Who owns each policy and who signs off on exceptions. Its outputs are policies and decision records with named owners.

Risk

The what-could-go-wrong layer. Identify threats to the business, score likelihood and impact, assign an owner, track the treatment. The output is a risk register that someone actually maintains.

Compliance

The prove-it layer. Evidence that you meet obligations imposed from outside: laws such as the PDPA in Singapore or the Privacy Act in Australia, standards such as ISO 27001, regulator expectations such as MAS TRM, and the security clauses buried in customer contracts. The output is audit evidence.

The category has a formal pedigree. OCEG, originally the Open Compliance and Ethics Group (a name almost nobody spells out any more), codified it in its GRC Capability Model, which treats the three as one integrated capability rather than three departments. That framing matters in practice. A control like "encrypt all laptops" is at once a governance decision, a risk treatment and a compliance requirement, and if you record it three times in three places the copies start to disagree.

What does a GRC platform replace?

It replaces the spreadsheet stack: a controls matrix in Excel, policies in a shared drive, the risk register in another tab, and audit evidence scattered across screenshots and old email threads. Each artefact works on its own. Together they fail as a system, because nothing connects a control to the policy that mandates it or to the evidence that proves it ran.

The scale is easy to underestimate. ISO 27001:2022's Annex A alone lists 93 controls, and each needs an implementation statement plus evidence an auditor will accept. Add a second framework and the work more than doubles. You are now maintaining a many-to-many mapping between two control sets by hand, where every edit risks a silent inconsistency. Shared drives make it worse, because two people editing the same matrix will eventually overwrite each other and nobody notices until the auditor does.

None of this is beyond a disciplined team running one framework. The platform earns its keep on the joins, not on any single artefact. A controls tab is easy. Keeping it consistent with the evidence folder and a second framework is the part that never stays done.

Who actually needs one?

You need one when any of three triggers fires: you take on a second framework, you chase your first enterprise deal, or you book your first external audit. Before that, a well-kept spreadsheet is genuinely adequate. Pretending otherwise is vendor talk.

The second framework is the sharpest trigger. A Singapore fintech holding ISO 27001 that now needs to evidence MAS TRM, or an Australian firm adding SOC 2 because a government buyer expects Essential Eight maturity as well, discovers the same thing: the frameworks overlap heavily but not identically, and reconciling them by hand becomes a permanent part-time job nobody was hired for.

The first enterprise deal arrives as a security questionnaire, often hundreds of questions long, and procurement wants structured answers with evidence attached rather than a reassuring paragraph. Slow answers read as weak security. Buyers notice.

The first external audit makes the same demand in the other direction. An auditor works control by control while you excavate the shared drive, and the fee clock runs either way. For what that engagement involves, see our guide to preparing for a first ISO 27001 audit.

There is an honest counter-case. If you hold one certification and your customers never send questionnaires, you can defer the purchase without much pain.

What does a GRC platform cost?

For small and mid-sized organisations, published vendor pricing typically lands between US$5,000 and US$30,000 a year. Where you fall in that band depends on how many frameworks you run, how many systems you connect for automated evidence, how many seats need access, and whether services such as audits or penetration tests are bundled in.

Enterprise tiers are "contact sales", and sit well above that band.

Weigh the fee against what the spreadsheet stack already costs. The visible cost is internal hours spent chasing screenshots and rebuilding control matrices every audit cycle. The hidden one is the enterprise deal that stalls while a questionnaire sits unanswered in someone's inbox.

If you take one step before buying anything, make it a single control register. Zavior's cross-framework register holds each control once and maps it to every framework that asks for it.

Which frameworks matter for Singapore SMEs?

For most Singapore SMEs, the frameworks that decide deals are MAS TRM if you sell into financial services, CSA Cyber Essentials and Cyber Trust (CTM:2025) for cybersecurity credibility, DPTM for demonstrating PDPA-grade data protection, and ISO 27001 or SOC 2 when overseas customers ask. Which of them you need depends on who is buying from you.

Start from your sales pipeline. A fintech supplying a bank will be assessed against MAS TRM expectations by the bank's vendor risk team. A SaaS company chasing regional enterprise deals will hit ISO 27001 questionnaires. A firm handling large volumes of personal data can use IMDA's Data Protection Trustmark (DPTM) to show PDPA compliance in a form procurement teams recognise. CSA's mark scheme has two tiers, Cyber Essentials for baseline hygiene and Cyber Trust under CTM:2025 for more mature organisations, and both now appear in Singapore tender and vendor-assessment paperwork.

Here is the practical problem. CTM:2025 and DPTM are absent from most US-built compliance tools. The big automation platforms were built around SOC 2 and grew outward, so a Singapore SME buying one often ends up automating frameworks its customers never mention while running MAS TRM and Cyber Trust in spreadsheets on the side. Before you sign anything, ask the vendor to show you the Singapore frameworks working in the product. A roadmap slide does not count.

How do the main tools compare?

Vanta and Drata lead on US-framework automation depth and integration breadth. Sprinto competes on price and speed for the same global frameworks. Zavior is the one built around the Singapore stack. No single tool wins every column, so compare them on three criteria: Singapore framework coverage, pricing in SGD, and support hours in your timezone.

Be honest about the trade-offs, because they are real. Vanta and Drata have had years and serious funding to build integration catalogues and automated evidence collection for SOC 2 and ISO 27001. If your only goal is a SOC 2 Type II for US customers, their automation depth is hard to beat, and Zavior is not the obvious pick. Zavior's integration catalogue is narrower, and its US-framework automation is younger than what the incumbents offer.

If your buyers are all American, buy the American tool.

The calculation flips when Singapore frameworks enter the picture. Zavior covers MAS TRM, ISO 27001, SOC 2, NIST CSF, CTM:2025, CIS Controls, Essential Eight and DPTM, with cross-framework mapping between them, so an access-control policy written once satisfies its counterpart control in each framework instead of being re-evidenced four times. If MAS TRM or Cyber Trust sits anywhere on your two-year plan, a tool that treats them as first-class frameworks saves you from running a second, manual compliance programme alongside the automated one.

What does pricing look like in SGD?

Expect annual contracts that scale with headcount and with the number of frameworks you switch on, and expect most global platforms to quote in USD rather than SGD. That second point matters more than it looks. A USD contract means FX movement between renewal dates, and finance teams at small companies notice when a "flat" subscription drifts.

None of the major vendors keep public price lists stable for long, so treat any number in a blog post (including this one) as stale on arrival and get current quotes. [PLACEHOLDER: verify indicative entry-level pricing for Vanta, Drata and Sprinto at time of writing] When you compare quotes, normalise them to SGD per year at your realistic framework count, not the single-framework teaser tier.

Two costs sit outside every platform subscription. Auditor and certification-body fees are always separate; the platform prepares the evidence, but a human auditor signs the report, and their fee is your line item. Staff time is the larger hidden cost. A tool with your actual frameworks built in costs less in practice than a cheaper one that leaves MAS TRM to a spreadsheet and a long-suffering ops lead.

Can grants offset the cost?

Yes. The Enterprise Development Grant (EDG) from Enterprise Singapore supports up to 50% of qualifying project costs, and compliance work can qualify when it is scoped as capability building rather than a bare software purchase. That distinction is the whole game. EDG funds projects, so a certification push with defined outcomes stands a far better chance than an invoice for a subscription.

Eligibility rules and what counts as a qualifying cost are set by Enterprise Singapore and do change, so check the current EDG terms on the EnterpriseSG site before you budget around the grant. Many SMEs pair the application with a consultant who has run the process before. If you go that route, confirm the consultant's costs are themselves claimable under the current rules instead of assuming it.

Confirm which framework your customers require and check EDG eligibility before you commit to a platform. Then pick the tool whose coverage means you will not pay twice, once for the software and once for the manual programme it leaves out. If your roadmap runs through MAS TRM, Cyber Trust or DPTM alongside ISO 27001, Zavior's cross-framework mapping lets you collect each piece of evidence once and reuse it across the whole Singapore stack.

This is general information, not legal advice. [Flag: lawyer review before publication]

Which frameworks do Australian buyers ask for?

Four local frameworks do most of the work in Australian security reviews: the ACSC's Essential Eight, the Information Security Manual (ISM), APRA CPS 234 for financial services, and the Privacy Act. Enterprise and international buyers layer ISO 27001 and SOC 2 on top, so a mixed pipeline usually means running four to six frameworks at once.

The Essential Eight is the one that surprises overseas vendors. The Australian Cyber Security Centre publishes it as a maturity model with four levels, Maturity Level Zero to Maturity Level Three (ML0 to ML3). ML0 means a mitigation strategy is materially absent. ML3 means it is implemented tightly enough to resist more capable adversaries. There is no pass mark and no certificate; you sit at a level, per strategy, and buyers ask which. See our guide to the Essential Eight maturity levels for what each level demands.

The other three pull different threads. The ISM is the control catalogue behind Australian government systems, and it shapes what agencies expect from their suppliers. CPS 234 is APRA's information security standard, and it reaches service providers who handle a regulated entity's information assets, so you can sit inside its blast radius without being a bank, insurer or superannuation fund yourself. The Privacy Act applies to most organisations handling personal information, which is why privacy questions now turn up in ordinary procurement questionnaires rather than waiting for legal review.

How do the main tools compare?

The market splits cleanly. US-built compliance platforms are strong on ISO 27001 and SOC 2 and thin on the Australian stack, while the deciding factor for an Australian buyer is genuine Essential Eight maturity tracking backed by AUD pricing and support in your time zone. Automation and integrations are broadly comparable across the category now.

Framework coverage is where shortlists actually get decided.

Regulated entities have a further test. APRA's CPS 230 has been in force since 1 July 2025, and it raises the bar for regulated entities on operational risk and how they manage service providers. Sell into an APRA-regulated customer and your GRC tool becomes part of how that customer evidences oversight of you. That pushes cross-framework mapping and continuous monitoring well above nice-to-have.

Zavior's coverage, stated plainly: Essential Eight with maturity tracking from ML0 to ML3, ISO 27001, SOC 2, NIST CSF, CIS Controls, and Privacy Act mapping.

Fill the competitor rows from current vendor documentation, not memory or review sites. Coverage in this category changes quarter to quarter, and sales decks lag reality in both directions.

What does pricing look like in AUD?

Mostly, it doesn't. The large platforms quote in US dollars, billed annually, with per-framework pricing that climbs each time you add a standard. An Australian buyer on that model carries exchange-rate movement across a multi-year contract and explains USD invoices to a finance team that budgets in AUD.

Structure matters more than the headline number. Before comparing quotes, ask: is the Essential Eight included or a paid add-on; does adding a framework mid-term reopen the whole contract; is support staffed during Australian business hours; and is the renewal quoted in the same currency as year one. A platform that looks cheaper per year stops looking cheap once the second framework and the currency spread land on the same invoice.

Zavior prices in AUD with Australian support. For competitor numbers, get a current quote in writing rather than trusting anything published. [PLACEHOLDER: verify current competitor list pricing and whether AUD billing is offered]

What about government supply chains?

Expect Essential Eight Maturity Level Two. ML2 is the common contractual target in government contracts, and it flows down the chain. Primes push the same requirement onto their subcontractors and SaaS suppliers, so you can inherit the obligation two steps removed from the department that wrote it.

The practical consequence is evidence, not certificates. A tender response that says "we take security seriously" loses to one that states a current maturity level for each of the eight mitigation strategies and can produce the records behind it (patch timelines, privileged-access reviews, backup test results, MFA coverage). Buyers ask to see the working.

Plan the gap honestly. Moving up a level is mostly engineering effort on things like patching cadence, administrative privileges, multi-factor authentication and backups; the software's job is to show where you stand today, per strategy, and to hold the evidence as you climb. If a department asks for ML2 and you are at ML1, saying so with a dated plan is a credible answer. Discovering it mid-tender is not.

If you are running the Essential Eight for a government prospect and ISO 27001 for an enterprise one, Zavior's maturity tracker and cross-framework mapping let one evidence base answer both questionnaires.

This is general information, not legal advice. [Flag: lawyer review before publication]

When do spreadsheets actually work?

Spreadsheets work when three things are true at once: one framework, fewer than 50 controls, and one person who owns the register. Inside those limits a well-kept workbook is the right tool. It costs nothing, and auditors accept it without comment. They care whether your controls operate, not what software records them.

The Essential Eight is the classic Australian starting case. Eight mitigation strategies and a target maturity level, usually with a single IT lead doing the implementing. A tab per strategy, a row per requirement, a status column, a link to the evidence. Nothing about that needs a platform.

The same holds for a first ISO 27001 gap analysis, or a one-off client security questionnaire. If the register changes monthly rather than daily, and nobody else edits it, the spreadsheet's weaknesses never get the chance to show. Buying software at this stage buys you admin, not assurance.

Where do they break?

Spreadsheets break when evidence has to stay fresh across more than one framework, which is where most growing Australian companies end up. Compliance is a set of claims that each need current proof, not a list of answers you fill in once. A spreadsheet records that the proof existed at some point. It has no way of telling you the proof has since expired.

Do the arithmetic on a single framework. ISO/IEC 27001:2022 Annex A contains 93 controls. If your auditor expects evidence refreshed quarterly (access reviews, patching reports, backup test results, firewall rule checks), that is roughly 370 artefacts a year to collect and file. Excel holds just over a million rows, and no compliance register in history has come close. Volume was never the issue. What the workbook lacks is any concept of freshness. The access-review screenshot from February sits in its cell looking exactly as valid in November, and nothing flags the difference.

Then the second framework arrives.

You keep the Essential Eight because your government clients ask about it, and you take on ISO 27001 because an enterprise deal demands certification, or SOC 2 because a US customer does. A large share of the controls overlap. Multi-factor authentication and patching sit on both lists, so every overlap becomes double data entry, and the two registers drift out of agreement within a quarter. The failure mode is never a full file. It is two files that disagree, in front of an auditor.

What does switching cost versus staying?

Switching costs a few weeks once. Staying costs a slice of every audit, forever. The honest comparison is hours per audit cycle, so here is the typical shape. Treat the numbers as illustrative ranges rather than quotes; scope and auditor move them, but the pattern holds.

Staying in spreadsheets, a surveillance audit on one framework commonly burns 40 to 60 hours chasing and re-collecting evidence, plus another 10 to 15 reconciling versions and re-checking which control answers which clause. Then there is the fortnight before the audit when normal delivery work quietly stops. Run two frameworks from separate workbooks and the chase roughly doubles, because the registers share nothing.

Switching typically costs a one-off 20 to 40 hours of migration, plus the subscription. Audit preparation then tends to fall to 10 to 20 hours, for two reasons: expired evidence surfaces continuously instead of in a pre-audit scramble, and one artefact satisfies every framework it maps to. On those ranges the switch pays for itself around your second audit or your second framework, whichever arrives first. For most companies that is the same year the first enterprise contract lands.

What are the warning signs it's time?

Four symptoms reliably mark the point where the spreadsheet costs more than software would: version conflicts, missed renewals, double-keyed controls and audit panic weeks. If two of them describe your last quarter, the trigger has already fired. The table is the checklist.

None of these symptoms is about running out of rows. Every one of them is about time. The register stops reflecting reality unless someone spends hours making it true, and that is the moment the workbook stops being free. For the overlap side in practice, see our guide to mapping controls across frameworks.

Keeping that register live is the job Zavior does for Australian teams, with each control mapped once across the Essential Eight and ISO 27001 and an expiry date stamped on every artefact.

What does the certification audit cost?

The certification audit typically costs a Singapore SME S$8,000 to S$20,000, and it comes in two parts. A stage 1 audit reviews your documentation and readiness. A stage 2 audit then tests whether your information security management system (ISMS) actually operates the way the documents claim. Both stages are priced into that range.

Certification bodies price in auditor-days. More staff means more days. So does a second office, and so does an ambitious scope statement. A 20-person software company certifying one office sits near the bottom of the range; a firm with several sites and a data centre in scope sits near the top. Get two or three quotes, because rate cards differ more than you would expect for identical scope.

One decision matters more than price. Choose a certification body accredited by the Singapore Accreditation Council (SAC). An unaccredited certificate is cheaper and worth close to nothing, because tender evaluators and procurement teams check the accreditation, and a certificate nobody recognises fails at exactly the moment you need it to work. The SAC register is public. Checking a certification body against it takes about a minute.

Consultant, platform, or both?

You have three ways to build the ISMS the audit will test. Hire a consultant to build it with you. Buy a compliance platform and do the work yourself. Or run a platform with a few consultant days bolted on. As typical ranges, consultant-led projects run S$20,000 to S$40,000 in fees, platforms run S$7,000 to S$15,000 a year, and hybrids land in between.

A consultant earns the fee by doing the heavy lifting: gap assessment, risk assessment, policy and control documentation, and usually your first internal audit. You move faster and burn fewer internal hours. The trade is that the knowledge can walk out the door when the engagement ends.

A platform is the cheaper cash outlay, but it is tooling, not labour. It structures the control set and keeps the evidence and the risk register in one place, while your team still does the thinking. The hybrid path is common for a reason. The platform handles day-to-day structure, and a consultant takes the two jobs that benefit most from an outside eye, the risk assessment and the internal audit.

Treat every figure here as a typical range, not a quote. A number well outside these bands deserves questions about scope before you sign anything.

What internal time should you budget?

Budget 300 to 500 internal hours in year one for a typical SME, concentrated in whoever owns the ISMS. This is the line most budgets miss, and hiring a consultant does not delete it. Someone inside still has to make the decisions and produce the evidence.

By role, the split usually looks like this. The ISMS owner or project lead carries 150 to 250 hours. IT and engineering spend 60 to 100 hours implementing controls and pulling evidence. Leadership gives 20 to 40 hours across risk workshops, policy sign-off and the management review, and every employee sits through an hour or two of security awareness training.

A worked example. A 30-person firm might log 200 hours for the lead, 80 for engineering, 30 for leadership and 45 across staff training. Call it 355 hours. At a fully loaded cost of S$60 an hour, that is about S$21,000 of salary redirected into the project. No invoice ever arrives for it, which is why a do-it-yourself certification is rarely as cheap as the cash figure suggests.

Putting the numbers together, a year-one budget breaks down like this:

What are the recurring costs?

Certification is not a one-off purchase. The certificate runs on a three-year cycle: a surveillance audit in each of years two and three, then a full recertification audit at the end of year three. Budget roughly a third of your year-one spend as the annual recurring cost.

Surveillance audits are shorter and cheaper than the initial audit because they sample the ISMS rather than reassess all of it. On top of the audit fee, the platform subscription renews, or you buy a smaller block of consultant days. The maintenance work carries on as well: internal audits, management reviews, risk register updates, corrective actions.

The expensive mistake is letting the ISMS decay between audits. An organisation that reconstructs a year of evidence in the fortnight before surveillance pays twice, once in staff overtime and again in findings that drag into the recertification.

Auditors recognise backfilled evidence when they see it.

Can grants reduce the bill?

Yes. The Enterprise Development Grant (EDG), administered by EnterpriseSG, supports up to 50% of qualifying costs for eligible SMEs, and consultancy-led certification projects are a common use of it. On a S$40,000 consultant-led build, that level of support can bring the cash cost close to what the do-it-yourself route would have cost anyway.

Two practical notes. Apply before the project starts, because grants are not awarded retrospectively. And check what counts as a qualifying cost, since support typically attaches to the consultancy work rather than to every line in your budget. Criteria and support levels change, so confirm the current terms with EnterpriseSG before you build the grant into the plan.

Whichever path you take, the audit mostly examines three things: your control register, your risk register and your evidence. Zavior keeps all three in one place, which is most of what a stage 1 auditor asks to see. For how the standard compares with its most common sibling, see our guide to ISO 27001 versus SOC 2.

This is general information, not legal advice. [Flag: lawyer review before publication]

What does the audit itself cost?

Expect A$10,000 to A$25,000 for the certification audit, quoted as auditor-days at the day rate on the certification body's rate card. That figure covers both stages. Stage 1 reviews your documentation; Stage 2 tests whether the information security management system (ISMS) actually operates the way the documents claim.

Who you buy from matters as much as the price. In Australia, JAS-ANZ accreditation (the Joint Accreditation System of Australia and New Zealand) is the mark of a legitimate certifier. Anyone can sell you a certificate. Only a JAS-ANZ-accredited body can sell you one that a buyer's security team will accept, so check the JAS-ANZ register before you sign the engagement letter, not after.

Get quotes from two or three accredited bodies. Day rates and quoted audit durations vary, and the quotes are itemised enough to compare like for like. Rate cards usually price travel as a separate line, so a certifier with auditors based in your city saves a little. The cheapest accredited certifier is not automatically the wrong choice. An unaccredited one always is.

What drives the price up or down?

Three variables set most of the quote: the scope of your ISMS, your headcount, and how many sites the auditor has to cover. Certification bodies feed them into standard tables that fix the minimum number of audit days, so each one moves the price directly.

Scope is the lever you control.

ISO 27001 lets you certify a defined scope, one product or one business unit, rather than the whole organisation. A tight scope honestly drawn around what your customers care about cuts audit days and cuts preparation work harder. Draw it so narrowly that it excludes the systems buyers ask about, though, and it will pass audit and fail sales calls. Buyers read the scope statement on the certificate.

Headcount matters because more people means more interviews and more evidence to sample. Sites matter because the auditor visits them, physically or virtually. A thirty-person single-office SaaS company sits at the bottom of the range. A two-hundred-person firm across three states does not.

Everything else in the first-year bill depends on how you prepare. Full-service consultants cost the most and leave the least knowledge behind. Compliance software plus a part-time internal owner costs less and keeps the knowledge in-house. Working straight from the standard with no help is cheapest on paper and slowest in practice. Here is how the first cycle typically breaks down:

What are the recurring costs?

Certification is a subscription, not a purchase. The certificate runs on a three-year cycle: a full audit in year one, a surveillance audit in each of years two and three, then a recertification audit to open the next cycle. Miss a surveillance audit and the certificate is suspended. Your customers' vendor-risk tools will notice.

Surveillance audits are shorter than the initial audit because the auditor samples the ISMS rather than reworking all of it, and they are priced off the same rate card. Ask the certification body to quote all three years up front so the recurring line is visible before you commit. Budget alongside it for the internal work the standard requires every year regardless: internal audits, management reviews, staff awareness training, and keeping the risk assessment current.

The recurring cost nobody puts in the spreadsheet is drift. Controls that were real at certification decay into documents nobody follows, and the year-two surveillance audit is where the gap surfaces. A named owner for the ISMS, even at a fraction of one role, is cheaper than rebuilding evidence in a panic every audit season.

Is it worth it versus SOC 2 or Essential Eight in Australia?

Match the framework to the buyer. Australian government buyers assess you against the Essential Eight. US enterprise buyers expect a SOC 2 report. Buyers across APAC and Europe ask for ISO 27001, and that is where the certificate earns its keep.

The Essential Eight is the Australian Signals Directorate's set of baseline mitigation strategies, and there is no certificate to buy. You demonstrate maturity against its eight controls. If government is your market, spend the money on that uplift before you spend it on any certification (see our guide to the Essential Eight maturity levels).

US enterprise security teams want SOC 2 because their vendor-risk process is built around it; an ISO certificate usually earns you a longer questionnaire, not a shorter one. ISO 27001 is the reverse case. It is the default ask across APAC and Europe. And it travels: one certificate answers a buyer in Sydney and a buyer in Frankfurt.

If you sell into more than one of these markets, the frameworks overlap heavily. The access-control and logging work you do for one substantially covers the others. The waste is running them as separate projects with separate evidence piles. Zavior's control register maps each control you operate across ISO 27001, SOC 2 and the Essential Eight, so you build the evidence once and answer every framework with it.

What's the actual difference between them?

SOC 2 is an attestation report: a licensed CPA firm examines your controls and issues an opinion under the AICPA's attestation standards. ISO 27001 is a certification. An accredited certification body audits your information security management system (ISMS) against the international standard and issues a certificate. That distinction sounds like accounting trivia. It decides who audits you and which buyers recognise the result.

A SOC 2 audit measures your controls against the AICPA's Trust Services Criteria. Security is mandatory; availability, processing integrity, confidentiality and privacy are optional additions you scope in if your customers care about them. The output is a long, detailed report, normally shared with customers under NDA. There is no such thing as being "SOC 2 certified". You hold a report containing an auditor's opinion, refreshed every year.

ISO 27001 certifies a management system rather than a bare list of controls. The auditor wants to see a scoped ISMS with a risk assessment, a Statement of Applicability, internal audits, management reviews, and the Annex A controls you have implemented as a result. What you get is a public-facing certificate you can put on your website, typically valid for three years with annual surveillance audits in between.

Which do buyers in Singapore and the region ask for?

ISO 27001 is the more commonly requested of the two across Singapore and most of APAC, while SOC 2 requests come overwhelmingly from US companies and US-headquartered multinationals. The sequencing question is really a question about your sales pipeline, not about which framework is better.

In Singapore, enterprise and public-sector vendor assessments routinely list ISO 27001 as the recognised baseline. It will not exempt you from a security questionnaire, but it shortens the argument, because an accredited third party has already verified that you run a working ISMS. Banks and insurers add their own outsourcing and technology-risk due diligence on top, shaped by MAS expectations (see our guide to the MAS TRM guidelines), and a certificate gives their assessors something concrete to anchor on.

The pattern holds across the region. Buyers in Japan, Korea, Australia and Europe default to ISO 27001 because it is the standard their own security teams are certified against. SOC 2 barely registers with many of them. Flip the geography and the preference flips too. A US SaaS buyer's security review almost always opens with a request for your SOC 2 Type II report.

The practical read for an APAC startup is simple. If your next four quarters of revenue are regional, start with ISO 27001 and add SOC 2 when a US deal puts it on the table. Selling into the US from day one? Reverse the order.

How long does each take?

Plan for months either way, but the clocks run differently. ISO 27001 timing depends on how quickly you can build and operate an ISMS before the audit. A SOC 2 Type II report cannot exist until your controls have operated through an observation window of 3 to 12 months. That window is a hard floor. The auditor is giving an opinion on operating effectiveness over a period, so the period has to happen first.

ISO 27001 certification runs as a two-stage audit: a Stage 1 review of your documentation and readiness, then a Stage 2 audit of the implementation. The audit itself is rarely the long pole. Producing a credible risk assessment takes longer, and so does building enough operating history (internal audits, management reviews) to show the system is real rather than a binder written the week before.

SOC 2 offers a shortcut and a trap. A Type I report covers control design at a point in time and can be produced relatively quickly, but many enterprise buyers discount it. For Type II, startups typically choose a shorter first observation window to get something into buyers' hands, then move to longer windows in later cycles. Either way the window only starts once your controls are actually operating. Start evidence collection early; auditor selection can wait.

How much does doing both cost and save?

Doing both costs far less than twice the price of one, because roughly 80% of the controls overlap. Access control, encryption, logging, incident response and vendor management satisfy both frameworks once implemented properly. The second audit is incremental. You pay for the delta, not for a second programme.

The delta runs in both directions. Coming from SOC 2, ISO 27001 adds the management-system layer: the scoped ISMS, risk assessment, Statement of Applicability, internal audit and management review. Coming from ISO 27001, SOC 2 adds period-of-time evidence mapped to the Trust Services Criteria, gathered continuously across the observation window rather than sampled at an annual audit.

The auditor's invoice is not the biggest cost.

Your own team's time producing evidence usually is, and that is where the 80% overlap pays out, but only if you treat your controls as one set. Run two disconnected spreadsheets, one per framework, and you will collect the same access-review screenshots twice and answer the same questionnaire twice.

The saving is concrete. Map each control to both frameworks before the first audit, and collect each piece of evidence once, against the control rather than against the framework. Zavior keeps that mapping in a single control register, so the evidence from your first audit arrives at the second already tagged.

What does a wiki do well?

A wiki is genuinely good at three compliance jobs: writing and versioning policies, onboarding staff to those policies, and recording who owns what. If your program today is "we need an information security policy, an acceptable use policy, and somewhere new hires can read them", Notion or Confluence does that job properly. You should not apologise for it.

Page history shows who changed a policy and what the previous wording was, which covers the version control ISO 27001 expects for documented information. A Confluence page tree can mirror your document hierarchy cleanly. A Notion database can hold owner, review date and status against every policy. That is more structure than most small teams manage in a shared drive.

For an Australian startup drafting its first policy suite ahead of an enterprise deal that asks about ISO 27001, this is real coverage, not theatre. Policies change slowly, they are prose, and prose is what wikis are built for. The trouble starts when the program stops being about documents.

Where does it silently fail?

It fails at evidence, which is the thing an audit actually tests. An auditor does not certify that your policies exist; they certify that your controls operate. That means access review exports, MFA configuration screenshots, backup logs and offboarding tickets, each tied to a specific control and each current for the audit period.

The hidden cost is the quarterly evidence refresh with no expiry alerts. Evidence ages quietly. An access review from February is stale by the September audit, but the wiki page it's pasted into looks exactly as healthy as it did the day you wrote it. Nothing flags it. Nothing tells the control owner it's due.

You discover the gap when the auditor asks for twelve months of operating evidence and you have one screenshot and a good story.

The second silent failure is mapping. ISO 27001 and the Essential Eight overlap heavily (patching, privileged access, backups, MFA), but a wiki has no way to say "this one control satisfies both frameworks, and here is its evidence". You end up with duplicated pages that drift apart, or one page an auditor can't trace to either framework.

What does the hybrid look like?

Keep the wiki as your policy library and run controls, evidence and tasks in a platform, with links between the two. Policies are prose that changes a few times a year. Leave them where your team already reads them. Controls and evidence change every quarter, and they need the structure a wiki can't give.

In practice, the platform holds your control register, mapped to ISO 27001 and the Essential Eight. Each control links out to the Confluence or Notion page that states the governing policy, and holds its own evidence and owner, plus a refresh date. The wiki stays the answer to "what do we say we do"; the platform becomes the answer to "can we prove we did it".

The hybrid demands one discipline. A policy lives in the wiki and nowhere else; a control lives in the platform and nowhere else. The moment someone copies the control list back into a Notion table for visibility, you have two registers, and one of them is wrong.

When is a full platform justified?

A platform earns its keep when your program crosses from writing to proving. Specific triggers tell you when that has happened. Any one of them is a reasonable prompt; two or more means the wiki is already costing you audit-week panic.

• A second framework arrives. ISO 27001 plus Essential Eight maturity reporting for a government buyer, say, or SOC 2 for US customers. Cross-mapping in a wiki means duplicated pages that drift.
• An external audit is booked. The auditor needs a scoped view of controls and evidence, not a guest login to your entire workspace.
• Recurring evidence outgrows memory. Once more than a handful of controls need quarterly refresh, "someone will remember" stops being a control.
• Security questionnaires become routine. Answering from a live control register takes minutes. Answering from page trees takes an afternoon, every time.
• A government or regulated customer asks for maturity evidence. Essential Eight claims need current, traceable evidence behind each mitigation strategy, not a page saying you patch promptly.

Below these triggers, the honest advice is to stay put. A wiki plus a disciplined spreadsheet is enough for a program that hasn't faced its first audit, and buying tooling before you have controls to put in it just gives you an empty register with a subscription attached. For what auditors actually ask to see, see our guide to audit evidence.

If you're at the hybrid stage, Zavior's control register maps each control to ISO 27001 and the Essential Eight and flags evidence before it expires, while your policies stay in the wiki your team already reads.

What does "audit-ready" actually mean?

Audit-ready means three things are true at once: every in-scope control is implemented and operating, evidence of that operation has been collected, and known gaps have been closed or formally accepted with a documented reason. Miss one and an auditor finds the seam in the first week of fieldwork.

Most teams over-weight the first item and ignore the second. A control that runs but leaves no trail does not exist for audit purposes. Access reviews done verbally. A backup restored once, never logged. The control operated; nobody can prove it. Evidence is half the definition, not an afterthought.

The third item matters because no company arrives at an audit gap-free. Readiness is not perfection. It is knowing exactly which controls fall short and being able to explain the risk decision behind the ones you chose to defer.

How long per framework?

SOC 2 Type I is the fastest route at six to ten weeks, because it tests control design at a single point in time. Anything with an observation window or a full management system takes months. The table assumes a small, cloud-native company using compliance automation; double the ranges for manual evidence collection or heavy on-premise infrastructure.

For Singapore companies the usual sequence is SOC 2 or ISO 27001 first, because customers ask for those, with MAS TRM alignment layered on for financial services clients and the Cyber Trust mark added when a tender demands it. (CSA also runs the lighter Cyber Essentials mark, a separate track for smaller outfits.) The Essential Eight row is there because plenty of SG companies sell into Australia or answer to an Australian parent. If that is you, budget it separately. Your ISO work will not cover it.

What stretches the timeline?

Technical control gaps stretch timelines. Documentation almost never does. Policies can be drafted and signed off in a fortnight; what cannot be rushed is engineering work with real dependencies and change windows.

The usual offenders. MFA coverage that is "done" except for a legacy VPN, three service accounts, the finance team's accounting portal and one director's ageing laptop. A patching cadence that exists on paper with no fleet management behind it. Backups that have never been restore-tested. Logs scattered across systems with no central retention. Offboarding that depends on someone remembering.

Each of these is a project, not a checkbox.

Closing the last 10 per cent of MFA coverage routinely takes longer than the first 90, because the stragglers are stragglers for a reason. The honest first step of any readiness effort is a gap assessment that separates engineering work from paperwork. The engineering list is your critical path; the policy list never is.

The second stretcher is evidence debt. If controls have been running but nothing was captured, you either automate collection going forward and wait, or reconstruct history by hand. Nobody enjoys the second option. For a Type II report the observation window makes waiting unavoidable anyway, so start collecting evidence before you think you need it.

What does week-by-week look like?

A workable SOC 2 Type I plan fits in ten weeks, provided the engineering gaps are ordinary and one named person owns the programme. The shape of it:

1. Week 1. Pick your Trust Services Criteria (Security at minimum), inventory systems and vendors, and give every control area a named owner.
2. Week 2. Run the gap assessment and sort every finding into two piles, engineering work and paperwork.
3. Week 3. Start the long poles now: MFA enforcement, patching automation, backup configuration. They run in the background for weeks.
4. Week 4. Adopt access control, change management, incident response and vendor management policies, with real sign-off rather than a folder of templates.
5. Week 5. Wire automated evidence collection into your cloud provider, identity provider, device management and code repositories.
6. Week 6. Review critical vendors' own reports, complete your risk assessment and document any accepted risks.
7. Week 7. Finish the MFA stragglers, run a backup restore test and log it, and tabletop the incident response plan.
8. Week 8. Walk every control end to end and confirm evidence actually exists for each one. Fix what falls out.
9. Week 9. Confirm scope with your auditor and remediate anything the week 8 review surfaced.
10. Week 10. Fieldwork for the Type I examination. Answer exceptions the same week they are raised.

ISO 27001 stretches the same shape across months and inserts an internal audit and a management review before certification. Essential Eight ML2 is weeks 3 and 7 repeated across every mitigation strategy, which is why infrastructure decides whether it takes three months or nine.

Most of that calendar is remediation, not paperwork, which is why a live controls register mapping each requirement to its implementation and evidence (the job Zavior does across SOC 2, ISO 27001, MAS TRM, CTM and the Essential Eight) is worth setting up in week one rather than week nine.

How does one control satisfy many frameworks?

Because most frameworks regulate the same underlying risks, a well-implemented control usually appears in every framework you adopt, under different names and different numbering. Mapping makes the overlap explicit. You implement the control once, record which clause of each framework it satisfies, and attach the same evidence to all of them.

Take multi-factor authentication (MFA). Every serious security framework requires it somewhere, because an attacker stealing a password is the same risk in Singapore, Australia or anywhere else. What changes between frameworks is the wording and the clause number, and sometimes the scope.

Suppose you enforce MFA for all remote access and all privileged accounts, with your identity provider's enforcement policy and its sign-in logs as evidence. Here is where that single control lands across four frameworks:

One control, four requirements answered. The evidence is identical in each case (an enforcement policy export plus authentication logs); only the clause reference changes. Multiply that across a register of eighty or a hundred controls and the arithmetic behind "comply once, certify many" becomes obvious.

What does mapping save in practice?

Most of the cost of a first certification is building the control environment: writing policies, deploying controls, collecting evidence, changing how people work. Mapping lets every later framework reuse that work. That is why a second framework typically costs a fraction of the first.

Gap analysis shrinks first. Instead of assessing every requirement from zero, you assess only the unmapped remainder, and for heavily overlapping frameworks that remainder can be a short list. Evidence collection collapses too, since artefacts gathered for the first audit are re-presented rather than re-created.

Staff feel it as fewer interviews. Nobody should answer the same MFA question four times.

The effect compounds. An organisation holding ISO 27001 that then pursues SOC 2, the Cyber Trust mark or Essential Eight alignment is closing a delta rather than launching a new programme (see our guide to choosing between ISO 27001 and SOC 2). Each framework you add enlarges the mapped register, which makes the next one cheaper still.

Where does mapping go wrong?

The classic failure is false equivalence: two requirements get treated as interchangeable because they sound alike, when one demands strictly more than the other. "Similar" is not "satisfies". Auditors test the requirement as written, not the label on your control.

MFA shows the trap neatly. One framework may accept any second factor for remote users while another requires MFA on every privileged account, internal systems included. A control that meets the weaker phrasing does not automatically meet the stronger one, even though both rows in your mapping say MFA. A useful mapping records scope and strength alongside the topic.

Two quieter traps: direction and scope. A mapping says your control satisfies requirement A and requirement B; it does not say A and B are equivalent to each other, so never chain mappings transitively. And evidence covering one entity or one system does not cover a certification scoped wider than that.

Then there is rot. Frameworks get revised and renumbered, and a mapping built against an old edition quietly points at clauses that no longer exist. Give the mapping an owner and a review cycle, like any other control.

How do platforms automate it?

Compliance platforms ship the mapping as a pre-built library. Every control in the register carries links to each framework requirement it satisfies, maintained in both directions: from a control you see everything it answers, and from any framework requirement you see which controls address it and whether current evidence is attached. The second direction is what makes adding a framework fast. Switch it on and the residual gaps are visible immediately.

Zavior maintains bidirectional mappings of this kind across MAS TRM, ISO 27001, SOC 2, the Essential Eight, Singapore's Cyber Trust mark (CTM) and the Data Protection Trustmark (DPTM). The DPTM is built on Singapore's PDPA; Australian readers should read the counterpart obligations as sitting under the Privacy Act. Evidence attached to a control once surfaces against every mapped requirement, so a multi-framework audit calendar draws on one register rather than the usual spreadsheet with a tab per framework and a colour code nobody remembers.

Automation handles the bookkeeping. The judgement stays with you. A platform can tell you that your MFA control is mapped to four frameworks and that its evidence is three months old; it cannot persuade an auditor that the evidence demonstrates the requirement. What a mapped register such as Zavior's changes is the starting point: each new certification begins as a delta project rather than a restart.

This is general information, not legal advice. [Flag: lawyer review before publication]

What does "failing" actually look like?

Certification audits don't end with a pass or fail stamp. They end with a list of findings, graded by severity. A minor nonconformity is an isolated lapse: the control exists and mostly operates, but the auditor's sample turned up a gap. A major is the absence or systemic breakdown of a required control, and majors are what people mean when they say they failed. (Auditors sample, by the way. They never read everything, which cuts both ways.)

The consequences differ sharply. Minors get a corrective action plan and are usually verified at the next surveillance audit. Majors block certification at an initial audit. Found at a surveillance audit, they start a clock, because certification body rules typically give you roughly 90 days to fix the problem and produce evidence. Miss the window and the body can suspend your certificate, then withdraw it.

SOC 2 works differently, since there is no certificate to suspend. You receive a report, and every control exception the auditor found is written into it. Failing a SOC 2 audit means receiving an opinion or exception list your buyers won't accept, which commercially amounts to the same thing. If you're weighing the two frameworks, see our guide to choosing between ISO 27001 and SOC 2.

Either way, the audit fee you already paid is sunk. What a bad audit actually costs starts the day the findings land.

What do the delays cost commercially?

The direct fees (remediation consulting, the auditor's follow-up work at standard day rates) are usually the smallest line. The expensive part is what a 90-day closure window does to deals that were waiting on your certificate or report.

The numbers below are illustrative. The mechanics are real.

Say you sell workforce software at an average of A$180,000 a year per enterprise customer. Two deals are sitting in security review, an ASX-listed insurer and a state government agency, both conditional on your ISO 27001 certificate. Then your stage 2 audit surfaces one major nonconformity. Closure eats most of the 90-day window: root-cause analysis, a corrective action plan, fresh evidence, a follow-up review before the certification decision.

Both deals slip a quarter. That defers roughly A$90,000 of revenue in the current year, and it assumes both buyers wait. The insurer's procurement team has a certified competitor in the same tender. If they don't wait, you lose the full A$180,000 a year, and that loss compounds for as long as the logo would have stayed.

Then add the internal cost. Closing a major pulls your engineering lead and whoever owns the failed control into remediation for weeks. That work displaces roadmap. The displaced roadmap has a cost too, even if it never appears on an invoice.

What if the failure becomes a breach?

An audit finding is a control failing in a controlled setting. The expensive version is the same control failing in production. IBM's Cost of a Data Breach 2025 report puts the global average cost of a breach at US$4.4 million, a different order of magnitude from any re-audit fee.

For an Australian organisation the breach scenario carries extras. Notification under the Privacy Act's Notifiable Data Breaches scheme brings the regulator into the room, and meanwhile your enterprise customers are re-reading the security questionnaire you completed during procurement. A breach traced back to a control an auditor had already flagged is the worst version of this story, because the finding becomes evidence that you knew.

Seen this way, an audit failure is cheap intelligence. You paid a certification body to find the broken control before an attacker did. The finding stings. It is also the discounted price of the same information.

What are the most common audit failures?

Across frameworks the same families of findings recur: stale access reviews, unmanaged vendors, and evidence gaps. None of them are exotic. They are maintenance work that slipped, which is also why each has a plain fix.

1. Access reviews that never happened, or happened without a record. The policy says quarterly; the auditor asks for the last four and gets one, undated. Fix it by scheduling reviews as recurring tasks with a named owner and recording who reviewed, when, and what they decided. The sign-off record is the control.
2. Leavers with live accounts. A sampled ex-employee still holds credentials weeks after departure. Tie deprovisioning to the HR offboarding trigger rather than to memory, and hunt for orphaned accounts in every access review.
3. Vendor management that stops at signing. Critical suppliers sit on the books with no due diligence on file and no reassessment since onboarding. Keep a vendor register with risk tiers, and put critical vendors on an annual reassessment cycle with the evidence attached.
4. Evidence gaps. The control genuinely operated (backups ran, patches shipped) but nobody kept proof, and reconstructing proof during audit week fails. Capture evidence at the moment a control operates, filed against the control it belongs to, not in a folder built the fortnight before the audit.
5. Corrective actions from the last audit left open. Nothing irritates an auditor faster than last year's findings, untouched. Track every finding to closure with an owner and a due date, and review the list monthly.

Most of these fixes are the same discipline wearing different clothes. Know your controls and who owns each one; collect the evidence as you go. That is the job a compliance register like Zavior's does year-round, so audit week becomes a retrieval exercise instead of a reconstruction.

This is general information, not legal advice. [Flag: lawyer review before publication]

[REQUIRES REAL CUSTOMER + SIGN-OFF BEFORE PUBLICATION]

What does MAS TRM require?

The MAS Technology Risk Management Guidelines set out the Monetary Authority of Singapore's expectations for how financial institutions manage technology risk. The current version dates from January 2021. It applies to every financial institution in Singapore, licensed fintechs included, so if you hold a MAS licence this is the document an inspector will measure you against.

Coverage is broad. The board and senior management own technology risk and set the risk appetite. Beneath that sits a working risk framework (identify, assess, treat, monitor) and then the operational domains: IT project management, software development and change, system availability and recovery, access control, data and network security, cryptography, incident management, and oversight of vendors and cloud providers. The January 2021 revision went deepest on third-party risk, including open APIs, and on cyber exercises informed by threat intelligence.

Two features of the Guidelines shape any readiness project. They are outcome-oriented, so an assessor wants controls that fit your risk profile rather than proof you bought a particular product. And they run on evidence. A policy with no logs, tickets, review records or drill reports behind it will not survive scrutiny, which is why the plan below starts collecting evidence in week 3 instead of week 7.

Where were the gaps?

The customer, [PLACEHOLDER: company profile: sector, MAS licence type, headcount, core stack, cloud footprint], commissioned a gap assessment against the 2021 Guidelines ahead of [PLACEHOLDER: trigger, e.g. licence milestone, partner bank due diligence, scheduled MAS engagement]. It surfaced [PLACEHOLDER: N] findings across three domains: access management, vendor oversight and incident readiness. The same three dominate nearly every first TRM assessment.

• Access management. [PLACEHOLDER: specific findings: state of privileged access reviews, joiner-mover-leaver process, MFA coverage] Assessors probe this domain hardest, because privileged accounts are the common thread in most serious incidents.
• Vendor oversight. [PLACEHOLDER: specific findings: missing due-diligence records for material outsourcing, no third-party register, absent contract clauses] The 2021 revision expanded third-party expectations, and this is where young fintechs are usually thinnest.
• Incident readiness. [PLACEHOLDER: specific findings: untested response plan, no drill history, unclear escalation and MAS notification path] A response plan that has never been exercised counts for little. Assessors ask to see drill reports.

Closure order was deliberate. Access management went first because its fixes are internal and quick to evidence. Vendor oversight started early and ran long, since due diligence waits on vendors answering questionnaires, the one dependency the schedule cannot compress. Incident readiness closed last by design; a drill is most useful once the new controls exist to be exercised.

What happened each week?

The project ran as three overlapping tracks: assess, implement, evidence. That parallelism is the whole trick. The gap report existed by the end of week 2, implementation began in week 3 while findings were still being finalised, and evidence collection started the same week, because most TRM evidence (access reviews, vendor files, drill reports, sign-off minutes) gets generated by doing the remediation work itself.

Two points generalise beyond this customer. Parallel tracks only work when the gap register is a live artefact with one named owner per finding; the moment it turns into a static spreadsheet, the tracks drift. And the week 6 drill deliberately preceded the week 7 dry run, so the drill's findings could be fixed and evidenced before anyone rehearsed the assessment itself.

Tabletop drills feel theatrical the first time. Run one anyway.

What would they do differently?

Asked in the post-project interview, the team named three changes: [PLACEHOLDER: lesson 1 headline], [PLACEHOLDER: lesson 2 headline] and [PLACEHOLDER: lesson 3 headline]. Their words follow.

[PLACEHOLDER: quote 1, expected theme: start vendor due diligence in week 1, since vendor response times are the one thing you cannot compress], [PLACEHOLDER: name, role].

[PLACEHOLDER: quote 2, expected theme: run the drill earlier and imperfectly instead of waiting for a polished plan], [PLACEHOLDER: name, role].

[PLACEHOLDER: quote 3, expected theme: appoint a single evidence owner from day one instead of collecting per team], [PLACEHOLDER: name, role].

The outcome: [PLACEHOLDER: outcome numbers: findings closed vs carried, assessment result, days from kickoff to sign-off, follow-up items]. Readiness did not end at sign-off either. The register stayed open, because the next assessment starts from whatever the last one left behind.

The gap register, control owners, due dates and evidence index for this project lived in Zavior, mapped clause by clause to the TRM Guidelines, which is what kept three parallel tracks from losing the thread.

This is general information, not legal advice. [Flag: lawyer review before publication]

[REQUIRES REAL CUSTOMER + SIGN-OFF BEFORE PUBLICATION]

What is the Essential Eight maturity model?

The Essential Eight is a set of eight mitigation strategies defined by the Australian Cyber Security Centre (ACSC), each assessed against four maturity levels numbered 0 to 3. The eight are application control, patch applications, configure Office macro settings, user application hardening, restrict admin privileges, patch operating systems, multi-factor authentication and regular backups.

The levels describe who you can withstand. Maturity Level 0 means significant gaps. ML1 counters commodity tradecraft, the sort of attack that uses widely available tools against any target that lets them in. ML2 counters adversaries willing to invest more time and capability in a specific target. ML3 addresses adversaries who adapt their tradecraft to defeat your particular controls.

Two features of the model catch people out. First, your overall rating is your weakest strategy. Seven strategies at ML3 and one at ML1 scores ML1. Second, the levels are packages, not menus. You implement every requirement at a level, across every in-scope system, before you can claim it. The ACSC also revises the model from time to time, so record which version you assessed against.

The subject of this case study is [PLACEHOLDER: MSP name, headcount, number of managed endpoints, states of operation, client mix], which needed ML2 because [PLACEHOLDER: driver, e.g. a government panel requirement or a flow-down clause from a Commonwealth client]. Its starting position was a self-assessed [PLACEHOLDER: e.g. ML1 on five strategies, ML0 on three].

Which strategies were hardest?

Application control and the two patching strategies dominated. Together they took roughly [PLACEHOLDER: share, e.g. 60%] of total project time, which is the usual shape of an Essential Eight uplift. The hard strategies are the ones that force you to enumerate everything that runs in your environment, and nobody starts with that inventory.

Discovery, in other words, was most of the bill.

Application control is hard because an enforced allow-list breaks anything you forgot. The MSP ran allow-listing in audit mode for [PLACEHOLDER: duration] before enforcing, and the audit logs surfaced [PLACEHOLDER: finding, e.g. line-of-business tools, updaters and scripts nobody had documented]. Enforcement without that discovery period would have taken down client-facing tooling on day one.

Patching is hard for the opposite reason. The requirement is simple, but meeting it continuously means vulnerability scanning on a fixed cadence and an owner for every asset the scanner finds. The MSP's first scans turned up [PLACEHOLDER: e.g. unmanaged servers and end-of-life software] with no patch owner at all.

Configuring Office macro settings, by contrast, was mostly policy work pushed through Group Policy. Multi-factor authentication was politically awkward and technically quick. [PLACEHOLDER: quote or observation from customer interview about user resistance and how it was handled]

What did each strategy take?

The table sets out the starting level and recorded effort for each strategy, alongside a summary of what ML2 required. Figures are for this environment ([PLACEHOLDER: endpoint count] endpoints across [PLACEHOLDER: number] client tenancies) and will scale with yours.

Sequencing mattered as much as the totals. The MSP ran application control and both patching strategies first, in parallel, because the discovery work (software inventory, vulnerability scans) fed every other strategy. Macro settings and user application hardening rode on the same Group Policy push. End to end, the uplift took [PLACEHOLDER: elapsed months] alongside business-as-usual work.

How is ML2 verified?

There are two routes: self-assessment against the ACSC's published maturity model, or an independent assessment by a third party. For Commonwealth-connected work the third party is typically an IRAP-endorsed assessor. Which route you need depends on who is asking. Many contracts accept a self-assessment; the buyer sets the bar.

Either way, the ACSC's assessment guidance expects controls to be exercised rather than asserted. An assessor does not read your allow-listing policy and nod. They attempt to run an unapproved executable and check that the blocked event landed in the central log. An honest self-assessment follows the same method, which is why evidence has to exist per strategy: scan reports, screenshots of enforced settings, restoration test records, log extracts.

The MSP chose [PLACEHOLDER: self-assessment / independent assessment, and why, e.g. the panel required an independent review]. The assessor's first-pass findings were [PLACEHOLDER: e.g. two strategies sent back for evidence gaps, closed within N weeks].

The practical lesson is that verification is an evidence problem, not a technology problem, and evidence is cheapest to capture while you do the work. Zavior keeps a running register that maps each of the eight strategies to its evidence and its owner, so the assessment pack exists before anyone asks for it.

This is general information, not legal advice. [Flag: lawyer review before publication]

What are the ten questions?

The first-pass questions cover certifications, breach history, data location, subprocessors, access, encryption, continuity, vendor management, insurance and audit rights. Every one of them has a model answer you can prepare before any buyer asks. Procurement uses the list to triage. A specific answer moves you into the full review; a vague one ends the conversation politely.

1. What security certifications do you hold? Name them exactly, with standard, type, scope and report date. If you hold none, say so in one sentence and give the roadmap in the next. Never let the buyer discover the gap themselves.
2. Have you had a data breach or security incident? Answer honestly, with dates, impact, root cause and what you fixed. A disclosed incident with a clean remediation story signals maturity. An implausible "never" signals a company that would not know.
3. Where is our data stored and processed? Name the cloud provider and the region. Singapore buyers frequently need data kept in-region, or advance notice before it moves, because transferring personal data offshore carries obligations under the PDPA that sit with them as well as with you.
4. Which subprocessors touch our data? Keep a published list naming each provider and what it does, with the hosting region, and offer notice of changes. An out-of-date subprocessor list is one of the fastest ways to fail a review.
5. How do you control access to customer data? Describe access on a need-to-use basis and MFA on everything, backed by a documented joiner-mover-leaver process. What procurement is really asking is simpler. When someone quits on Friday, when does their access die?
6. How is data encrypted? State encryption in transit and at rest, and say who manages the keys. Two sentences. If you cannot answer in two, that is itself the finding.
7. What happens if your service goes down? Give your backup frequency and the date of the last restore you actually tested, plus recovery targets if you have defined them. An untested backup is not a continuity plan. If the restore test is scheduled but not yet done, say when.
8. How do you manage your own vendors? Show that you assess critical suppliers before onboarding and re-check them on a cycle. The buyer is tracing whether their risk flows through you into companies nobody has examined.
9. What insurance do you carry? Cyber liability and professional indemnity, with limits stated and the certificate ready to attach. Insurance does not substitute for controls, but its absence stalls contract review.
10. Will you grant us a right to audit? Say yes, bounded by reasonable notice and frequency. Then offer reports instead: an audit report or a penetration test summary satisfies most buyers without anyone visiting your office.

Write the ten answers down once and have them reviewed. They do not change between deals.

What does a full questionnaire look like?

A full security questionnaire is a spreadsheet of control-by-control questions running into the hundreds. The most widely used standard format, the Cloud Security Alliance's Consensus Assessments Initiative Questionnaire (CAIQ), contains 261 questions in version 4. Buyers either send the CAIQ itself or a template derived from it; some push the same content through a third-party assessment portal instead.

The questions span governance, HR screening, physical security, change management and incident response. Most are yes/no plus a free-text justification, and the free text is what gets read. Expect the first pass to take days, and expect it to sit on your sales cycle. A deal cannot close while the questionnaire is open.

Two practical points. "Not applicable" is a legitimate answer when justified; a ten-person SaaS company has no data centre to badge into, and saying so crisply beats inventing a policy. Inconsistency kills. If question 40 contradicts question 190, the reviewer assumes neither answer is true.

One more thing. Some buyers re-send the entire questionnaire at contract renewal. Nobody warns you about that.

How do you answer without a certification yet?

You bridge with the three things procurement will accept in place of a badge: a dated roadmap, compensating controls, and evidence. The bridging language is a pattern, not a trick. "We have not yet completed [certification]. We have engaged an auditor and expect the report in [quarter]. In the meantime, the controls the certification would attest are listed below, with evidence available under NDA."

The roadmap must carry a date and a named auditor or scheme, or it is a wish. Compensating controls are the substance, meaning the access reviews, the encryption, the tested restore, the offboarding checklist. These are the things the certificate would have attested anyway. Evidence makes both credible: policies, architecture notes, penetration test results, screenshots of the control operating.

Two failure modes. "We take security seriously" with nothing attached reads as an admission. And never write "SOC 2 compliant" before you hold the report; procurement teams check, and one caught overstatement contaminates every other answer you gave. For choosing which certification to pursue first, see our guide to SOC 2 versus ISO 27001.

How do you make answering repeatable?

Build an answer library and publish its stable parts as a trust centre. The library is a maintained set of approved answers with evidence attached; the trust centre is its public face. The first questionnaire you answer is a cost. Every one after it should be mostly retrieval.

The library needs a named owner who approves wording, a review cadence so answers do not silently rot as your stack changes, version control so you know which answer went to which buyer, and a tag linking each answer to the underlying control. The tagging matters because a question about "logical access" and a question about "user provisioning" are usually the same control asked twice. The 261 CAIQ answers you write for the first buyer become the seed set for every template derived from it.

The trust centre publishes what is stable before anyone asks: certifications, the subprocessor list, a security overview, key policies. It shortens questionnaires by pre-answering the ten questions above, and it shows the buyer that answering them is routine for you. Which is itself an answer.

All of this is easier when the controls and their evidence already live in one register. Zavior keeps that register mapped across frameworks, so the same control answers the same question the same way in every deal.

This is general information, not legal advice. [Flag: lawyer review before publication]

How is it different from an annual audit?

An annual audit is a point-in-time exercise. An auditor examines evidence about your controls as they stood on a particular date, or across a defined review period, and issues an opinion. Continuous compliance monitoring checks the same controls automatically, daily or hourly or on every change, for as long as the integrations keep running.

The difference matters because controls decay quietly. An ISO 27001 certificate is issued after an audit and re-examined at annual surveillance visits. A SOC 2 Type II report covers a period, but the auditor tests samples from it, not every day of it. An Essential Eight assessment records the maturity level your environment demonstrated on the day the assessor tested it. None of these tells you whether MFA is still enforced this morning.

Between assessments, an organisation is effectively unobserved. A setting changed in August to work around a vendor outage can sit there until the following June, when someone finds it during audit prep and has to explain ten months of exposure. Continuous monitoring closes that gap. You observe the present all year instead of reconstructing the past once a year, and the annual exercise confirms what you already knew.

Neither replaces the other. A certificate says a qualified outsider agreed with you at a moment in time. A monitoring platform says the control is working right now.

What does it actually watch?

It watches whatever can be read from your systems programmatically: identity and access, cloud configuration, endpoint state, and the settings your chosen framework treats as controls. Every check is a comparison. Your control says a certain state should exist, your systems report the state that does exist, and a mismatch is drift. Most of it falls into a few recurring patterns.

• A new starter gets provisioned without multi-factor authentication, or an administrator disables MFA to troubleshoot a login problem and never re-enables it. MFA is one of the ACSC's Essential Eight, and the full coverage you showed at assessment rarely stays full on its own.
• An engineer flips a cloud storage bucket to public to share a file with a contractor, means to flip it back, and doesn't. The bucket sits open until someone notices. Ideally your tooling, not a stranger.
• An offboarded contractor still holds an active account, or a developer keeps admin rights from a project that wrapped up months ago. Restricting administrative privileges is another of the Eight, and privilege creep is the usual way it degrades. Nobody decides to break the control; it erodes one exception at a time.
• Endpoints and servers slip past the patching timeframes your framework sets. The Essential Eight maturity model is specific about how quickly exploited vulnerabilities must be patched, and patch lag is invisible until an assessor measures it. Or an attacker does.
• A backup job starts erroring silently. Regular backups are also on the Eight's list, and a job that has been failing for three weeks looks identical to a healthy one until you need a restore.

None of these is a decision to be non-compliant. Drift is almost always a reasonable person doing a reasonable thing under time pressure, minus the follow-up. Watching beats remembering.

What can't be automated?

Anything that requires judgement rather than a machine-readable state. A platform can confirm your access-control policy document exists and was reviewed on schedule; it cannot tell you whether the policy fits how the business actually operates. Vendor reviews are similar. Software can log that a review happened, but a human still has to read the supplier's SOC 2 report or questionnaire answers and decide whether the residual risk is acceptable.

Training is the sharpest example. Completion rates are automatable. Whether anyone would recognise the phishing email that matters is not. Risk assessments, scoping decisions and incident response exercises stay human work too, and a vendor who implies otherwise is overselling.

So a green dashboard proves the technical layer is standing. It does not prove the programme is sound. The organisations that get burned are the ones that let automated coverage of the measurable controls become an excuse to skip the unmeasurable ones. Continuous monitoring shrinks the manual workload; it doesn't abolish it.

What changes at audit time?

The evidence already exists. Instead of spending weeks screenshotting admin consoles and exporting user lists to reconstruct the review period, you hand the auditor a timestamped record of each control's state across the whole period, and they sample from it.

Auditors still run their own procedures. Independence requires it, and a good one will verify your monitoring rather than take its word. But the conversation changes shape. "Show me evidence MFA was enforced in February" becomes "explain this exception on 14 February and what you did about it." Exceptions with a remediation trail are routine findings. Evidence that cannot be produced at all is what blows out fieldwork.

The same logic applies to an Essential Eight uplift. The assessment still needs the assessor's own testing, but a year of continuous data means walking in with no surprises. The controls that drifted were caught and fixed when they drifted, not discovered in the fortnight before. Audit prep stops being a season and becomes a meeting.

If you run controls across more than one framework, say the Essential Eight for your board and ISO 27001 for your enterprise customers, a register like Zavior's maps each monitored control to every framework it serves, so one drift alert updates your evidence everywhere.

How do they compare on frameworks?

Vanta and Drata are built around the frameworks American buyers ask for. Zavior covers the global staples too, but its centre of gravity is the Singapore and Australian regulatory set. MAS Technology Risk Management (TRM). The CSA Cyber Trust mark (CTM:2025). The Data Protection Trustmark (DPTM) and the Essential Eight. A name on a vendor's list is the shallow question, though. The deeper one is whether the frameworks your regulator wrote are mapped against the ones your customers ask for, or bolted on as standalone templates.

Zavior's coverage, stated plainly: MAS TRM, ISO 27001, SOC 2, NIST CSF, CTM:2025, CIS Controls, the Essential Eight and DPTM. Each control is held once and reused across every framework that demands it. PDPA and Privacy Act obligations sit alongside as the data-protection layer for Singapore and Australia respectively.

The competitor columns are deliberately unfilled. Framework lists change quarter to quarter, and a comparison that guesses is worse than useless. [PLACEHOLDER: verify current Vanta and Drata framework lists against their published documentation before publishing.] When you do check, test depth as well as presence. A downloadable MAS TRM template is not the same thing as controls written against the guideline's clause structure. For what the category does as a whole, see our guide to what a GRC platform is.

How do they compare on price?

Zavior publishes its range. Plans run from S$2,400 to S$14,400 a year at the time of writing (SGD, annual subscription), banded by organisation size, with the largest organisations quoted individually. Current Vanta and Drata figures: [PLACEHOLDER: verify Vanta and Drata pricing models and typical annual ranges at time of publication.]

Price the certification, not the software.

The audit itself is billed separately by the audit firm, whichever platform you run. Ask what adding a second framework costs and which integrations sit behind a higher tier, and get the year-two renewal figure in writing. The cheapest year one is frequently the most expensive year three.

Where does each genuinely win?

Vanta and Drata win on the American side of the table: more integrations, deeper automation on US frameworks, and a name procurement teams in the US already know. None of that is spin. More connectors to the standard SaaS stack means more evidence collected with no human in the loop, and a security review moves faster when the reviewer has seen the report format before.

Zavior wins where the regulator writes the framework. MAS TRM controls built against the guideline text rather than translated from a SOC 2 baseline. CTM:2025 and DPTM preparation for Singapore's certification schemes. Essential Eight maturity tracking for Australian government work, with PDPA and Privacy Act obligations handled in the same system. The mapping layer carries most of the value. One access-control measure answers MAS TRM, ISO 27001 and the Essential Eight at once, where parallel checklists would quietly drift apart.

And the losses, said out loud. Choose Zavior and you accept fewer integrations, less automation depth on US frameworks, and a brand your American prospect's security team has not heard of. Choose Vanta or Drata and you accept that the framework with supervisory consequences may be an add-on rather than the core of the product. A comparison that hides the author's losing categories is an advert. This one is not.

Which should you choose by scenario?

Choose by who holds power over your revenue. When American buyers hold it, pick a US tool; when a Singapore or Australian regulator holds it, pick Zavior. The three cases below cover most buyers.

The US-bound SaaS company first. Headquartered in Singapore or Sydney, revenue from American enterprise, and the only document blocking deals is a SOC 2 Type II report. No regulator here asks anything of you beyond baseline PDPA or Privacy Act hygiene. Pick Vanta or Drata. You would be buying automation for a US buyer's framework, which is exactly what those two products are for, and paying for APAC regulatory depth you do not need optimises for the wrong audience.

The MAS-regulated firm. You hold a MAS licence (payments, capital markets services, whatever the class), so TRM compliance is supervisory expectation rather than preference, and inspections work clause by clause. Pick Zavior. You need controls written against TRM's structure and a mapping that lets that same control set answer an ISO 27001 auditor without a second register. CTM:2025 and DPTM sit within reach of the same controls when customers start asking.

The Australian firm selling to government, with a little US revenue. Buyers expect Essential Eight maturity (the model runs from level zero to level three, and buyers usually specify the level they want), the Privacy Act governs your data handling, and two American prospects want SOC 2. The regulator-driven frameworks win. Pick Zavior for the Essential Eight and Privacy Act work and let cross-framework mapping carry the SOC 2 overlap, rather than running a second platform for two prospects. Revisit only if US revenue overtakes government revenue.

Whichever way you land, keep one artefact vendor-neutral, a single control register mapped across every framework you answer to. That mapping layer is the piece of Zavior worth trialling even if the rest of your stack stays American.

This is general information, not legal advice. [Flag: lawyer review before publication]

Why does GRC vocabulary deserve its own glossary?

Because the words carry consequences. GRC terms look like ordinary English, but each has a precise meaning fixed by a standard or a regulator, and using them loosely costs real time. Tell an auditor you audited a vendor when you actually sent them a questionnaire and you have overstated your evidence. Call a guidance document a certification and you have promised a customer something that does not exist.

Precision here is cheap. Rework is not.

A shared vocabulary also shortens projects. A surprising amount of every kickoff meeting goes on discovering that "control" means one thing to the engineer and something else entirely to the auditor. Settle the definitions once and the arguments that remain are the useful ones.

The definitions below follow the vocabularies the standards bodies and regulators publish themselves: ISO's terminology standard, the ACSC glossary, and the published guidance of the PDPC in Singapore and the OAIC in Australia. We have restated them in plain sentences rather than standardese.

How is this glossary organised?

The first 12 entries cover the core audit vocabulary that every framework shares. The remaining 38 cover the wider GRC vocabulary plus the Singapore-specific and Australia-specific terms you meet locally. Each entry answers in one or two sentences and stands on its own, so you can cite a single definition without dragging the rest of the page along.

One layout note. The Singapore edition of this glossary (zavior.ai) lists the Singapore terms first: PDPC, DPTM, CTM, MAS TRM. The Australian edition (zavior.au) leads with the ACSC, the ISM, IRAP and the APPs. The definitions are identical on both sites; only the order changes.

There is no separate FAQ section on this page. Every entry is already a standalone question and answer, which is the job an FAQ would otherwise do.

What do the 12 core audit and control terms mean?

The 12 definitions below cover the machinery every audit runs on, from the control itself through to the gap assessment that usually starts a certification project. Whatever your framework or market, these come first.

Control

A control is any measure that modifies a risk, whether a policy, a process, a technical configuration or a physical safeguard that prevents, detects or corrects something going wrong. When an auditor asks how you control access, they want the specific measure and the name of the person who runs it.

Evidence

Evidence is the record proving a control actually operated, such as a log export, a signed policy, a completed ticket or a system report. In an audit, a control without evidence is treated as a control that did not run.

Framework

A framework is a structured set of requirements or good-practice controls that an organisation measures itself against. ISO 27001, SOC 2, MAS TRM and the ACSC's Essential Eight are all frameworks; some are certifiable, others are guidance you self-assess or attest against.

Audit

An audit is a formal, evidence-based examination of whether your controls meet a defined standard, carried out by someone independent of the work being examined. The word comes from the Latin for hearing, because accounts were once checked aloud; the independence requirement has outlived the reading.

Attestation vs certification

Certification is a pass-or-fail decision by an accredited certification body against a published standard; ISO 27001 works this way and produces a certificate anyone can verify. An attestation is an independent practitioner's opinion on your controls, delivered as a report (SOC 2 is the common example) that you share with counterparties.

Nonconformity

A nonconformity is an audit finding that you failed to meet a specific requirement of the standard. A major nonconformity signals a systemic breakdown and can block or suspend certification; a minor one is an isolated lapse you correct by an agreed date.

Residual risk

Residual risk is the risk left over after your controls have done their work, the exposure you are consciously living with. Auditors expect it stated in your risk register and formally accepted by someone senior enough to own it.

Statement of applicability

The statement of applicability (SoA) is the ISO 27001 document that lists every control in the standard's Annex A and records whether you apply each one, with the reason either way. Auditors read it first because it defines exactly what your certification covers.

Risk register

A risk register is the living record of your identified risks, each with an owner, a rating, the controls treating it and the residual risk left over. Usually the first artefact an auditor or regulator asks to see.

Control mapping

Control mapping matches one framework's controls to another's so that a single control, and the evidence behind it, can satisfy several frameworks at once. It is how teams avoid running a separate compliance programme for every certificate they hold.

Surveillance audit

A surveillance audit is the lighter periodic check, typically annual, that a certification body performs between full certification audits to confirm your management system still operates. It samples rather than re-examines everything, but its findings carry the same weight.

Gap assessment

A gap assessment compares your current controls against a framework's requirements and lists what is missing before an auditor does it for you. It carries no pass-or-fail consequence, which is why it is normally step one of any certification project.

Which 38 terms complete the glossary?

The remaining 38 entries span general GRC vocabulary, five Singapore-specific terms and six Australia-specific ones. Each will follow the pattern above: answer first, complete on its own.

[TODO: define remaining 38, same pattern]

General GRC (27): risk appetite · risk acceptance · inherent risk · risk treatment · compensating control · corrective action · observation (audit) · audit scope · ISMS (information security management system) · certification body · stage 1 vs stage 2 audit · recertification audit · continuous monitoring · control owner · policy vs procedure · policy exception · access review · data classification · security questionnaire · third-party risk management (TPRM) · SOC 2 Type I vs Type II · bridge letter · penetration test · vulnerability assessment · business continuity plan (BCP) · incident response plan · materiality.

Singapore-specific (5): PDPC (Personal Data Protection Commission) · DPO (data protection officer) · DPTM (Data Protection Trustmark) · CTM (Cyber Trust Mark) · MAS TRM (Technology Risk Management Guidelines).

Australia-specific (6): ACSC (Australian Cyber Security Centre) · ISM (Information Security Manual) · IRAP (Infosec Registered Assessors Program) · NDB scheme (Notifiable Data Breaches) · APPs (Australian Privacy Principles) · Essential Eight.

Most of these terms name artefacts an auditor will eventually ask to open. A definition helps; a current risk register helps more. Zavior keeps those artefacts and the evidence behind them in one tracked place, so the term and the thing it names stay in step.

What compliance work does AI do well today?

AI is genuinely good at three compliance jobs: drafting documents, mapping controls between frameworks, and answering security questionnaires from an existing evidence base. Those three share a property. The source of truth already exists somewhere, and the AI is transforming it rather than inventing it.

Drafting is the most visible win. A first-draft information security policy scoped to your actual stack used to mean a consultant's template and a fortnight of edits. Now it takes an afternoon of review. The draft is rarely right, but it is a competent starting point, and starting points were most of the cost.

Mapping is the quieter one. If you hold ISO 27001 and a customer asks for SOC 2, someone has to work out which of your existing controls satisfy which criteria in the new framework. That used to be days of spreadsheet work by whoever knew both standards. AI does a credible first pass in minutes. A human then checks the edge cases instead of building the whole matrix by hand.

Questionnaires are where founders feel it most. A 300-question security questionnaire from an enterprise prospect used to stall a deal for weeks. AI that retrieves answers from your approved answer library (previous responses plus current policies) can produce a reviewable draft in an hour. The keyword is retrieves. It works because the answers already exist and were checked once by a person.

What do auditors accept?

Auditors accept AI-assisted policies and evidence when a named human has reviewed the material and attests to it. Published audit-body statements converge on the same position: the method of production is not the audit question. Accountability is.

An auditor has never cared whether your access control policy was typed or adapted from a template. They care whether it describes what you actually do, and whether the person who owns it can answer questions about it in interview. AI drafting changes none of that. What carries audit weight is the attestation itself: a named person and a review date.

In practice this means keeping review records alongside AI-assisted documents. When the auditor samples your policies and asks the owner what a clause means, "the tool wrote it" is not an answer that survives the interview. "I reviewed it in March, and that clause covers our contractor offboarding" is. The bar has not moved. The work of clearing it has shifted from writing to reviewing.

The corollary is worth stating plainly. An unreviewed AI-generated document is not evidence of anything. It is a liability with formatting.

What breaks when you over-automate?

Three failure modes account for most AI-related compliance damage: hallucinated controls, unowned policies, and evidence nobody read. All come from the same mistake, which is treating generation as the finish line rather than the starting gun.

Hallucinated controls are the sharpest risk. Ask a general-purpose model to describe your encryption practices and it will describe encryption practices. Plausible ones. Possibly not yours. If that answer goes into a questionnaire, you have made a false representation to a customer. If it goes into a policy, you are now non-conformant against your own document: a generated policy that promises quarterly access reviews you never run is a finding waiting for its audit.

Unowned policies are subtler. AI makes it cheap to produce a complete policy suite in a week, so teams do, and end up with a shelf of documents no individual has actually read, let alone owns. The first auditor interview exposes this immediately. A policy without an owner who can speak to it is worse than a gap, because a gap is honest.

Evidence nobody read completes the set. Automated collection can pull screenshots and log exports into an audit folder continuously, which feels like progress. If no human reviews the pile, contradictions ship straight to the auditor: the exported user list that still includes the contractor your offboarding policy says was removed, or the backup log that quietly stopped in April. Automation raised the volume of documentation. Your review capacity is now the constraint, and pretending otherwise is how clean-looking programmes fail messy audits.

How does AI become a compliance object itself?

The AI you use has itself become something to govern. ISO/IEC 42001, the management system standard for AI, has been certifiable since December 2023, which means "how do you manage your AI?" now has a formal, auditable answer.

You do not need certification to feel the pull. Enterprise questionnaires increasingly include an AI section asking what models you use and what data they touch. If AI drafts your policies and answers your questionnaires, then your compliance tooling needs a named owner and a risk assessment of its own, and customers who ask deserve a straight answer about it. The loop closes. The system that helps you comply is in scope for the compliance it helps produce.

Australia has signalled the same direction locally. The Department of Industry, Science and Resources published the Voluntary AI Safety Standard in September 2024, a set of voluntary guardrails for organisations deploying AI. Voluntary is the operative word, for now. The standard reads as a preview of where Australian regulation is heading, and an organisation that adopts the guardrails early is doing what early ISO 27001 adopters did. They built the muscle before any obligation arrived.

The practical starting point is unglamorous: a register of where AI is used in your organisation and what data each use touches, with a named owner for every entry. ISO 42001 starts by asking for that list, and so does the DISR standard. Your customers' questionnaires are getting there too.

Keeping that thread straight is register work: which documents were AI-assisted, and which named person attested to each. That is the kind of record Zavior is built to hold.

This is general information, not legal advice. [Flag: lawyer review before publication]

What does the EDG cover?

The Enterprise Development Grant (EDG) covers up to 50% of qualifying costs for consultancy-led projects, which in practice means engagements where an external consultant helps you build a capability your business does not yet have. Compliance work fits that shape well. A gap assessment against a recognised standard is a project. So is an ISO 27001 readiness programme.

The distinction matters. The EDG is not a discount voucher for software, and it will not subsidise business-as-usual IT spend. EnterpriseSG funds defined projects with a clear end state, and it expects a consultant's proposal that spells out what gets delivered and when. Qualifying cost categories shift from time to time, so check the current list before you budget [verify current terms].

If you were going to do the compliance work anyway (an enterprise customer's security questionnaire is the usual trigger), structuring it as one scoped consultancy engagement rather than a series of ad-hoc fixes can roughly halve the cash cost.

What do CSA schemes fund?

The Cyber Security Agency of Singapore (CSA) supports SMEs along two certification pathways plus a consultancy programme. The Cyber Essentials mark targets organisations that need baseline cyber hygiene. The Cyber Trust mark is built for organisations with greater digital exposure. CISO-as-a-Service, the third scheme, gives SMEs subsidised access to cybersecurity consultants.

CISO-as-a-Service is the usual entry point. An appointed consultant assesses where you stand and produces a cybersecurity health plan tailored to your business, then works with you towards Cyber Essentials or Cyber Trust certification. For a company with no in-house security lead, that is exactly what the name promises. A chief information security officer you rent rather than hire.

Funding levels and consultant panels under these schemes are set by CSA and revised periodically [verify current terms]. Treat any figure you read in a blog post, including the table below, as a prompt to check CSA's own pages.

IMDA separately supports SME digitalisation, including lists of pre-approved solutions. If your gap is tooling rather than advice, look there before you scope a consultancy project [verify current terms].

Grant terms change. The figures in this table were checked in July 2026. Confirm current rates and criteria on the Business Grants Portal and CSA's website before you budget.

Who is eligible?

For the EDG, your business must be registered and operating in Singapore and have at least 30% local shareholding. Those two tests decide most applications before the project itself is even assessed. Confirm them first, particularly the shareholding test if you have foreign investors on the cap table.

EnterpriseSG also looks at whether the company can fund and complete the proposed project. A grant reimburses. It does not front cash. If the project would strain your cash flow even at half price, size it down rather than hoping the approval letter changes the arithmetic.

CSA's SME schemes carry their own criteria, aimed broadly at smaller organisations without in-house security capability. The definition of an SME differs from scheme to scheme, so read the current conditions on CSA's pages rather than assuming the EDG tests carry over.

How do you apply?

EDG applications go through the Business Grants Portal. CSA programmes such as CISO-as-a-Service are applied for through CSA directly. For the EDG, the sequence looks like this:

1. Scope the project before you shop for money. Define the capability you are building and what finished looks like.
2. Get a written proposal from your consultant covering scope, milestones, deliverables and costs. EnterpriseSG assesses the project, and a vague proposal reads as a vague project.
3. Log in to the Business Grants Portal (you will need Corppass access) and submit the application before the project starts. Costs incurred before you apply are generally not supported, so do not sign the consultant's contract first.
4. Respond to EnterpriseSG's follow-up queries promptly. Requests for clarification are routine rather than a bad sign, but they add weeks if they sit in an inbox.
5. On approval, deliver the project, then submit your claim with evidence of completion and payment to receive the reimbursement.

For CSA's schemes, start from the agency's Cyber Essentials, Cyber Trust and CISO-as-a-Service pages, which set out the current application route and the panel of appointed consultants.

The grant ends at certification. The obligations do not.

If your funded project ends in a mark or a standard, a compliance register such as Zavior keeps the controls, evidence, owners and renewal dates live afterwards, so the audit you paid half price for does not need rebuilding from scratch next year.

This is general information, not legal advice. [Flag: lawyer review before publication]

What lands each quarter of 2026?

The fixed statutory dates cluster in the second half of the year. Q1 and Q2 carry no hard, verified 2026 deadline. Q3 brings CPS 230's legacy-contract cut-off (1 July) and the EU AI Act's high-risk obligations (2 August), and Q4 closes with Australia's automated-decision transparency rules (10 December).

The first half is not empty. It belongs to cycle-driven obligations: surveillance audits and financial-year attestations that run on your own certification or fiscal calendar rather than a statute's.

This table was last reviewed in July 2026. We re-check regulator announcements monthly and add dates as they are fixed. A quarter showing only cycle-driven entries means no new date had been announced at the last review; plenty may still apply to you through your own audit cycle.

Which deadlines bite Singapore companies?

Mainly one: the EU AI Act's 2 August 2026 date, which reaches Singapore companies through the Act's extraterritorial scope. None of the three headline dates comes from a Singapore regulator. That does not make the year quiet.

The AI Act applies based on where an AI system is placed on the market or where its output is used, not where the company behind it is incorporated. A Singapore SaaS business with EU customers can fall in scope without a single EU office. So can a manufacturer exporting AI-enabled goods. If that describes you, the work for the next twelve months is classification. Work out whether what you ship counts as high-risk under the Act, because that answer drives everything else (see our guide to the EU AI Act for exporters).

Singapore's own regulators mostly run on continuous obligations rather than single dated deadlines. MAS technology-risk expectations for financial institutions apply year-round, and so do PDPC's obligations under the PDPA. Licence conditions can carry their own reporting dates; check yours. The absence of a headline Singapore date in 2026 is a quirk of timing, not a grace period.

Which deadlines bite Australian companies?

Two of the three: CPS 230's legacy-contract transition ends on 1 July 2026, and the amended Privacy Act's automated-decision transparency requirements commence on 10 December 2026. Australian exporters can add the EU AI Act's 2 August date on the same reasoning as their Singapore counterparts.

CPS 230 already applies to APRA-regulated entities. What changes on 1 July 2026 is the carve-out. Contractual arrangements that pre-dated the standard have been running under transitional relief, and that relief ends; from that date, every material service-provider arrangement must meet the standard. In practice, renegotiation or exit of legacy contracts needs to be finished by mid-year, not started. Contract remediation drags. If yours has not begun, it is the most urgent item on this page.

1 July is also the first day of the Australian financial year, which is partly why regulatory change piles up on that date.

The Privacy Act change is broader and lighter-touch. From 10 December 2026, organisations covered by the Act must be open about where automated systems make decisions that significantly affect people. The preparatory work is an inventory. Find every place a system decides or substantially shapes a decision about an individual (credit, eligibility, pricing, moderation), then update your privacy disclosures to match before the date. The inventory is the slow part; do it first.

What's already visible for 2027?

One date is already fixed. From 2 August 2027, the EU AI Act's high-risk obligations extend to AI systems embedded in products already covered by EU product-safety legislation. That matters for manufacturers whose goods go through EU conformity assessment and now carry AI components.

Treat 2026 as the scoping year and 2027 as the engineering deadline. Classification and gap analysis belong this year; redesign and conformity work belong next. Firms that leave both to 2027 discover their component suppliers are answering the same questionnaires for fifty other customers at once.

More 2027 dates will firm up as regulators publish implementation timetables, and they will appear in the table above once verified. If you would rather not maintain the list by hand, Zavior's regulatory tracker maps each dated obligation to the controls and contracts it touches, so a new deadline turns up as a task in your register instead of a surprise in your inbox.

This is general information, not legal advice. [Flag: lawyer review before publication]