3 Which? Frameworks and Standards
Which yardstick do you measure Tessera against, and why not all of them?
🗂️ Tessera Case: “Why can’t we certify against everything?”
The board meeting runs long. Tessera’s CTO has the slide up: ISO/IEC 27001, NIST CSF, the ASD Essential Eight, SOC 2, PCI DSS, a privacy overlay. “We’re a SaaS company serving enterprise and government customers,” she says. “Surely more badges is more trustworthy. Why not certify against all of them?” It is a reasonable question from a reasonable person, and it is exactly the wrong instinct. Your answer is not “pick one.” It is “pick the right one, and use the rest as cross-checks.” The whole meeting turns on why that distinction matters, and it sets the criteria every later chapter in this engagement will be measured against.
3.1 Frameworks are tools, not trophies
Before you choose, get clear on what these things actually are. A framework is a structured set of expectations: what good looks like, organised so an organisation can find its gaps and an auditor can test against them. They differ in scope, in origin, and, crucially, in what you can do with the result.
Some frameworks are certifiable. ISO/IEC 27001 is the canonical example: an accredited body audits you against it and issues a certificate the market recognises. Certifiable frameworks are scarce and valuable precisely because the opinion behind them is independent and repeatable. Anyone can claim compliance; only a certified body can back the claim.
Others are assessment or maturity frameworks. NIST CSF and the ASD Essential Eight live here. You can score yourself against them, an assessor can rate your maturity, and the result is genuinely useful. But there is no certificate to hang on the wall. They describe posture, not proof.
This distinction is the source of the board’s confusion, and it is worth naming out loud in the room. “More badges” only counts if the badges are the kind procurement teams and regulators actually ask for. For Tessera, chasing ISO/IEC 27001 is not a stylistic choice; it is the answer to a specific business question, and the other frameworks answer different questions. Your job in that meeting is to choose the framework that answers the question you are actually being asked, then explain why the rest come along for a different reason.
3.2 ISO/IEC 27001:2022: the certifiable yardstick
ISO/IEC 27001 is the standard Tessera will be certified against, and it earns that role for a specific reason: it is the internationally recognised, certifiable ISMS standard. An ISMS, an information security management system, is not a checklist. It is a management system: a set of policies, processes, risk decisions, and controls that an organisation runs continuously and that an auditor judges as a living thing. The standard’s clauses 4 through 10 lay out how that system is built: understand your context, set leadership accountability, plan around risk, support it with resources and competence, operate it, evaluate its performance, and improve it. Plan, do, check, act, repeated forever. When you audit 27001, you are auditing whether that loop actually turns, not whether a binder of policies exists.
The 2022 edition restructured Annex A, the controls catalogue, decisively. The 2013 edition scattered 114 controls across 14 domains that were easy to read but hard to reason about. The 2022 edition collapses them to 93 controls organised into four themes, and the themes are almost self-explanatory:
- A.5 Organizational controls (37): the governance, policy, supplier, and risk-management controls. The “what we have decided” theme.
- A.6 People controls (8): the employment-lifecycle controls, screening, terms, training, disciplinary process.
- A.7 Physical controls (14): the offices, the server room, the clear-desk rules, the physical entry logs.
- A.8 Technological controls (34): access control, cryptography, logging, secure development, the things most people picture when they hear “security.”
If you are going to hold one framework in your head as the yardstick, hold this structure. The themes map onto the way a real organisation divides its work: people who decide, people who are employed, places that are secured, and technology that is configured. When you test a control, you immediately know which part of the business it touches and whose evidence you will need.
One pairing worth remembering: 27001 is the certifiable standard, and its companion ISO/IEC 27002 gives implementation guidance for each control. You audit against 27001; you reach for 27002 when you need to understand what a control is actually asking for. They are a pair, and confusing them is a common rookie mistake. The certificate says 27001. The “how do I do this well?” book is 27002.
3.3 NIST CSF 2.0: the functions lens
The NIST Cybersecurity Framework takes a different cut through the same problem. Where ISO 27001 organises by who does it, CSF organises by what you are trying to achieve, expressed as six functions:
Govern, Identify, Protect, Detect, Respond, Recover.
The newest of these, Govern, is the headline change in CSF 2.0 (released in 2024), and it is the one that matters most to an auditor. The older version treated governance as something that lived outside the framework. Version 2.0 puts it squarely inside, recognising that the technical functions fail when nobody owns the decisions. Governance is where accountability, risk appetite, policy, and oversight live, and pulling it out of the wings and onto the stage is the single most consequential revision in the update.
CSF is not certifiable, and that is a feature rather than a limitation. It is a communication and orientation framework. You use it to explain posture to a board, to map what you have, to spot whether your coverage is lopsided (heavy on Protect, thin on Detect, say). For an auditor it is an excellent cross-check because it asks a question ISO 27001’s themes do not: do you cover the full lifecycle, from understanding what you have through to recovering when it breaks?
One warning that catches people out: CSF is not a control catalogue. It is functions, then categories, then subcategories that reference other standards. It points at controls rather than containing them. That is why it pairs so well with ISO 27001, and why using it instead of a control standard leaves you with posture and no proof. Posture tells a story; an audit needs evidence. CSF supplies the story; 27001 is where the evidence is tested.
3.4 The ASD Essential Eight: the baseline
The Essential Eight is the most specifically Australian artefact in the set, and for a Perth company chasing government work, that specificity is its value. Published by the Australian Signals Directorate, it is a baseline: eight mitigation strategies the ASD judges most effective at stopping common attacks.
The eight are deliberately concrete and unglamorous: application control, patching applications, configuring Microsoft Office macros, user application hardening, restricting administrative privileges, patching operating systems, multi-factor authentication, and regular backups. Each is scored across maturity levels 0 to 3, from “not implemented” through to “fully managed and tested.” A government customer asking for your Essential Eight maturity is not asking for a certificate; they are asking a pointed question about how well you do the unglamorous basics.
Two things to keep straight. First, the Essential Eight is a baseline, not a complete framework. It will tell you whether your patching and admin-privilege hygiene is sound; it will not tell you whether your supplier risk management is adequate or your incident-response plan works. Treat it as the floor, not the ceiling. Second, it was designed around Microsoft-centric estates, which fits most organisations but not all. For Tessera, built on AWS with a mix of tooling, some strategies map cleanly and some need interpretation. That interpretation is exactly the kind of judgement the standard cannot supply and the auditor must.
I will admit a personal bias here, because it shapes how I use these frameworks. The Essential Eight is the one I reach for first when I want to know whether an organisation can be hacked tomorrow. The others tell me whether it is well-governed; the Essential Eight tells me whether the doors are locked. Both questions matter, but on the day of an incident, only one of them was the difference.
3.5 Pick one yardstick, cross-check the rest
Now the actual decision, and the one the board meeting is really about. You do not certify against multiple frameworks because certification is expensive, the audits overlap, and “we are certified against everything” is not a signal of trust but a signal that nobody chose. The mature move is to pick one framework as the yardstick: the thing you measure, certify, and score against. Then use the others as cross-checks: lenses that expose gaps the yardstick hides.
For Tessera the choice is almost made for you. The business goal is a certificate that enterprise and government customers will accept. That is ISO/IEC 27001:2022. So 27001 becomes the yardstick. NIST CSF 2.0 becomes the cross-check that asks whether the controls add up to a full Govern-to-Recover lifecycle. The Essential Eight becomes the cross-check that asks whether the baseline technical hygiene actually holds. Three frameworks, one opinion, each doing a job the others cannot.
The temptation, especially under a board that has read the marketing, is to chase every badge. “We’ll do ISO 27001, SOC 2, PCI, the lot.” Each certification is a real engagement with real cost, and the marginal badge is worth less than the marginal effort. Worse, organisations that spread themselves across many frameworks rarely do any one well: they collect mappings instead of building controls. The discipline is to choose the yardstick that answers the business question, certify against it, and let the rest inform rather than multiply the work. A company that certifies against one standard thoroughly beats a company that maps against five superficially, every time.
3.6 Mapping and reconciling
Once you have a yardstick, you map. The point of a cross-mapping is not to prove the frameworks are equivalent; they are not. It is to confirm you have no blind spots, and to translate evidence so a control tested once can satisfy multiple audiences. A government customer wants to see Essential Eight maturity; a board wants CSF posture; your certification auditor wants 27001 evidence. One well-built mapping lets all three read the same controls in their own language.
The mapping is many-to-many, and saying so plainly saves you from the most common mapping error. One ISO 27001 control, access reviews, touches Protect and Detect in CSF and several Essential Eight strategies (admin privileges, MFA, application control). One Essential Eight strategy, patching, maps to a technological control and to organizational policy. A neat one-to-one table is a lie. An honest many-to-many table is a working paper you can defend.
And here is the auditor’s scepticism applied to the frameworks themselves: a mapping is an assertion about correspondence, and assertions get tested. When someone hands you a cross-mapping, your job is to spot the row that claims two controls are equivalent when they are merely adjacent. “Both talk about logging” is not “both require the same evidence.” Frameworks overlap; they do not coincide. The discipline of mapping is the discipline of saying exactly how much two controls actually share, and no more.
Now the worked artefact, and the place where AI earns and then loses your trust.
🗂️ Tessera Case: Choosing the yardstick, and the starter map
You take the board through the decision on one slide. Yardstick: ISO/IEC 27001:2022, because certification is the business goal and 27001 is the certifiable answer. Cross-check 1: NIST CSF 2.0, to confirm the controls span Govern through Recover. Cross-check 2: the ASD Essential Eight, because government customers expect the baseline and Tessera wants the work. The board signs off, not because more is better but because each framework now has a defined job.
You start the cross-mapping as a working paper, not a deliverable, and you keep it honestly many-to-many. A representative slice:
| ISO/IEC 27001:2022 (yardstick) | NIST CSF 2.0 (cross-check) | ASD Essential Eight (cross-check) |
|---|---|---|
| A.5.15 Access control | PR.AA (Identity, authentication, authorization) | Restrict administrative privileges; MFA |
| A.8.7 Protection against malware | PR.IR; DE.CM | Application control; user application hardening |
| A.8.13 Information backup | RC.RP | Regular backups |
| A.8.19 Installation of software on operational systems | PR.IR (Platform security) | Patch applications; patch operating systems |
| A.5.7 Threat intelligence | ID.RA; DE.AE | (no Essential Eight equivalent; the baseline does not cover it) |
The last row is the one to notice. Threat intelligence is a real 2022 control with no Essential Eight home, and a mapping that pretends otherwise is precisely the lie this table refuses to tell. Cross-checks expose gaps as honestly as they expose coverage, and a gap you have named is a gap you can manage.
This is a task AI is genuinely good at drafting and genuinely dangerous at finishing. Ask an AI to “produce a cross-mapping of ISO/IEC 27001:2022 Annex A to NIST CSF 2.0 and the ASD Essential Eight,” and it returns a clean, plausible table in seconds. Most of it is right. That is the trap.
Two confabulations to hunt for. First, stale control numbers. Models trained on older corpora quietly cite 2013 Annex A numbers, A.9.x for access control and A.12.x for operations, as if they were current 2022 controls. They are not; the 2022 renumbering retired them. Every control number must be checked against the actual 2022 Annex A before the table leaves your desk. Second, invented entries. In one run the AI helpfully added a row for “Configuration baselining” under the Essential Eight column. The Essential Eight has exactly eight strategies, and that is not one of them. The model pattern-matched “configuration management” to something that should exist and then asserted it did.
Your correction is the work: count the Essential Eight strategies (you will find eight, never nine), verify each 27001 number against the current standard, and re-classify the many-to-many relationships the AI flattened into tidy one-to-one rows. The AI gave you a draft that saved an hour. The hour you spent correcting it is where the defensible opinion was built. Drafter to evaluator, exactly as the Introduction described.
The frameworks were written before generative AI sat inside the estate, so no control is labelled “AI.” That does not mean AI is uncovered. Treat an AI deployment as what it is: a cloud-delivered, data-hungry, rapidly-changing software system, and the 2022 controls land on it hard.
The 2022 edition is unusually well-timed here, because several of its new controls are the very ones an AI deployment makes load-bearing. A.5.23 Information security for use of cloud services applies directly, since most enterprise AI is consumed through a cloud API and Tessera’s data leaves its boundary to reach the model. A.5.7 Threat intelligence matters more, not less: model-abuse techniques, prompt-injection trends, and data exfiltration via tool calls are exactly the threat intel a current ISMS needs. A.8.11 Data masking applies to the training and prompt data that may carry personal information. A.8.25 Secure development life cycle (and its partner A.8.28 Secure coding) applies to the pipelines that build, fine-tune, and deploy models. And A.5.30 ICT readiness for business continuity applies the moment a business process depends on an AI service that can degrade silently.
The audit move is to take each AI system in scope, walk it through these controls, and ask the standard question: what evidence proves this control is present and working for this system? An AI deployment does not earn an exception. It earns a closer look.
Add your framework-selection working paper to the locker. Record three things: the yardstick and why it was chosen (ISO/IEC 27001:2022, because certification is Tessera’s business goal); the cross-checks and the question each one answers (CSF 2.0 for lifecycle coverage; the Essential Eight for baseline hygiene); and a starter cross-mapping table with at least a dozen controls mapped honestly many-to-many, with gaps explicitly noted rather than papered over. This is the standard against which every later control test in this audit will be judged. Get the yardstick wrong and the whole engagement measures the wrong thing.
3.7 The question, answered
Which yardstick? The one that answers the business question you are actually being asked. For Tessera that is ISO/IEC 27001:2022, chosen not because it is the only framework but because certification is the goal and 27001 is the certifiable answer. NIST CSF 2.0 and the Essential Eight come alongside it as cross-checks, each exposing what the yardstick alone would hide: one the full Govern-to-Recover lifecycle, the other the technical baseline your government customers expect.
And “why not all of them?” Because collecting frameworks is not the same as building controls. The mature organisation picks one yardstick, certifies against it thoroughly, and lets the others inform the work without multiplying it. The discipline of choosing, and then of mapping honestly, is itself an audit skill: it is professional scepticism applied to the standards before you ever apply them to Tessera.
You now have your criteria. The next question is the one that turns criteria into a plan: what exactly are we auditing, on what terms, and how? That is scope, and it is where the engagement stops being a reading exercise and becomes a method.