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 separates the requested certification from other binding obligations and optional 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 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. An accredited certification body can issue accredited certification within its scope. Other assurance engagements have different mandates and reporting rules.
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. These are not ISO-style certification schemes. An assessment against their outcomes can still be evidence-based; its report should state scope, method and limitations.
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. CSF 1.1 already included governance under Identify. Version 2.0 elevates it to its own function, as NIST’s change summary explains. 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. Its outcomes need translation into criteria and evidence requests appropriate to the engagement. Evidence can support a CSF assessment as well as an ISO assessment; neither framework supplies proof by itself.
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, whose requirements address increasing adversary capability and techniques. They are not generic labels for documentation or management maturity; consult the ASD maturity model for the strategy-specific requirements. 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.
A strong Essential Eight result does not establish immunity from compromise. Its coverage is bounded; supplier governance, service architecture and additional obligations need their own assessment.
3.5 Pick one yardstick, cross-check the rest
Use a principal standard to organise this engagement, while recording every other binding criterion. Tessera wants ISO/IEC 27001 certification, so that is the principal standard. CSF and the Essential Eight are supplementary lenses unless a contract or other obligation makes particular outcomes mandatory. A payment obligation or privacy duty cannot be dismissed because it sits outside the preferred framework.
Multiple assurance programmes may be justified by different customers. SOC 2 is an attestation report on controls relevant to selected Trust Services Criteria, not an ISO certificate. A Type II report addresses a period; a report’s scope, exceptions and user responsibilities matter to reliance. AICPA’s SOC 2 overview describes its purpose.
3.6 Applicability before the test plan
The Statement of Applicability (SoA) records necessary controls, why they are included, implementation status and justified Annex A exclusions. Risk treatment can require controls beyond Annex A. The management-system requirements remain part of the audit; “not applicable” is not a way to remove an inconvenient requirement.
Read E03’s teaching extract. “Implemented” with no evidence reference is a management claim to test. A.5.18 concerns access rights; A.6.5 concerns responsibilities continuing after employment. A numbered control reference alone does not establish a precise operational deadline. Here the two-hour and 24-hour criteria come from the fictional policies.
This edition uses ISO/IEC 27001:2022 with Amd 1:2024, the climate-action amendment. Record consideration of climate-related relevance to organisational context and interested-party requirements; do not silently omit the amendment. Use authorised copies for exact normative wording. The source guide identifies editions and the limits of these teaching paraphrases.
3.7 Supplier assurance before exclusions
E09’s fictional SOC 2 summary covers a payment API through December 2025. It has an exception and complementary user controls, with no supplied 2026 bridge evidence. Read the subject, service, period, report type, exceptions and customer responsibilities before deciding what reliance is justified.
Do not exclude supplier oversight merely because a processor performs the transactions. You may lack authority to test the provider directly, yet still need to test Tessera’s selection, contracts, monitoring and complementary controls. An unavailable report or missing period belongs in the evidence-gap register. Chapter 4 carries that limitation into scope and procedures.
3.8 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.
Apply the same scepticism 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.
🗂️ 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 category-level slice, not a claim of full outcome equivalence. PR.PS is Platform Security; PR.IR is Technology Infrastructure Resilience. Verify subcategories and required evidence in the CSF 2.0 Core:
| 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.PS; DE.CM | Application control; user application hardening |
| A.8.13 Information backup | PR.DS; RC.RP (recovery use) | Regular backups |
| A.8.19 Installation of software on operational systems | PR.PS (Platform Security) | Application control (partial overlap) |
| 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.
An illustrative draft maps “A.8.19 → PR.IR (Platform Security) → patching” as an exact equivalence. Check it in stages. Platform Security is PR.PS. Software-installation restrictions and patch management overlap, but are not the same requirement. An installation allow-list test does not establish timely patching. Correct the category, state partial overlap and specify each separate test.
Do not upload a licensed standard to a model without permission. Public control titles and original teaching criteria are enough for this exercise.
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.
Relevant 2022 controls include both newly introduced controls and controls carried forward or reorganised from the prior edition. 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.
Time: 25 minutes. No AI required. Build a criteria sheet from E01, E03 and E09. Record the principal standard, the two policy deadlines, the supplier-report scope and missing period, and three necessary control areas from the SoA extract. For each, name evidence you would need. Classify the two-hour/24-hour conflict as unresolved, not an invitation to choose the easier test.
3.9 The question, answered
Framework choice establishes what the engagement will assess. Applicability and a criteria register make that choice testable. Keep contractual and legal obligations visible even when a single standard organises the report. Next, turn the criteria into a bounded programme.
3.10 Take it to the AI
This optional exercise follows the paper task. Use only E03’s original teaching criteria and the illustrative mapping above.
Role: Review a trainee’s criteria mapping.
Task: Identify unsupported equivalence claims. Do not invent standard wording or unseen evidence.
Context: The proposed mapping treats installation restrictions as proof of timely patching. Platform Security is PR.PS; PR.IR is Technology Infrastructure Resilience. The book’s case has not supplied a patch test.
Format: For each claim, give the supporting supplied fact, the missing test and a bounded correction.
Check the answer against the source and your criteria sheet. Keep a correct answer if supported; disagreement is not a required performance.