TL;DR
- Salesforce security findings can be mapped to NZISM v3.8, the NZ Privacy Act 2020, HISO 10029:2022, ISO/IEC 27001:2022, SOC 2, OWASP Top 10 and the Security Benchmark for Salesforce.
- A useful mapping is exact: it cites the specific control, the framework version, and the official control title, not a loose tag.
- For New Zealand organisations, NZISM and the Privacy Act are the frameworks that matter; a US-built scanner that maps only to HIPAA does not fit.
- A mapping shows where findings land against a framework. It is not an attestation of compliance.
What You'll Learn
- Which security frameworks a Salesforce org can be assessed against, including the New Zealand standards
- Why an exact, version-pinned control mapping is worth more than a framework tag
- How a single Salesforce finding maps across several frameworks at once
- Where to find the authoritative source for each standard
The Problem
A Salesforce security finding and a compliance control are written for different readers. "Three administrators have no MFA registered" is what an engineer fixes. "NZISM Chapter 16, Authentication and Access Controls" is what a CISO reports against and an auditor signs off. Most Salesforce security tooling stops at the first sentence, which leaves the compliance team to translate every finding by hand.
Common Questions This Article Answers:
- Does a Salesforce security audit map to NZISM and the NZ Privacy Act?
- How do I show that a Salesforce org meets ISO 27001 or HISO 10029 controls?
- Why do US-built Salesforce security tools map to HIPAA instead of New Zealand standards?
Quick Answer
Yes. Salesforce security findings can be mapped to the controls they implicate across seven frameworks: OWASP Top 10:2021, SOC 2 (AICPA Trust Services Criteria), ISO/IEC 27001:2022, the Security Benchmark for Salesforce, the NZ Privacy Act 2020, HISO 10029:2022, and NZISM v3.8. The mapping is only useful if it is exact, so each control is cited with its identifier, the framework version it is mapped against, and the official control title taken from the published source. For New Zealand health and government organisations, the mapping includes NZISM, HISO and the Privacy Act, which a generic offshore scanner leaves out.
Why the mapping has to be exact
A loose tag such as ISO 27001 on a finding is worse than no tag. It implies a precision the tool cannot back up. The first time a CISO checks it against the standard and finds it wrong, every other mapping in the report loses credibility with it.
So a defensible mapping is not a list of tags. It is a sourced control catalogue, where each control carries four things:
- its exact identifier, for example
NZISM-AC,ISO-A.8.15, orSBS-AUTH-004 - the framework version it is mapped against: ISO/IEC 27001:2022, NZISM v3.8, the current editions
- the official control title, taken verbatim from the source
- a citation back to that source
A control should only appear in a report after its title and reference have been confirmed against the published standard. Building a catalogue this way surfaces real errors before they reach a client: outdated control identifiers, a framework pinned to a superseded version, controls mapped to the wrong criterion. Verification against the source fixes each one.
The frameworks a Salesforce org maps to
Three frameworks are universal. One is specific to Salesforce. Three are specific to New Zealand.
Universal
- OWASP Top 10:2021 (owasp.org/Top10/2021). The common language for application security risk.
- SOC 2, AICPA Trust Services Criteria (aicpa-cima.com). The Common Criteria, CC6 through CC9, that enterprise procurement asks a vendor to evidence.
- ISO/IEC 27001:2022 (iso.org/standard/27001). The Annex A controls, restructured in 2022. The international baseline.
Salesforce-native
- Security Benchmark for Salesforce (SBS) (docs.securitybenchmark.org). An independent, CIS-style benchmark written specifically for the platform. It encodes Salesforce-specific controls a generic scanner does not know about: guest user record access, the "Use Any API Client" permission, connected app token policy.
New Zealand
- NZISM v3.8 (nzism.gcsb.govt.nz). The New Zealand Information Security Manual, maintained by the GCSB's National Cyber Security Centre. The baseline any agency handling government information aligns to.
- HISO 10029:2022 (healthnz.govt.nz). The Health Information Security Framework, built on the ISO/IEC 27002 control set.
- NZ Privacy Act 2020, Information Privacy Principles (privacy.org.nz). IPP 5 covers storage and security of personal information; IPP 12 covers disclosure outside New Zealand. This applies to every organisation that holds personal information.
Why the New Zealand standards are the point
A Salesforce scanner built in the United States maps to HIPAA. HIPAA is United States health law. It does not apply to a New Zealand organisation, and putting it at the top of an audit reads as a tool that was never built for this market.
New Zealand organisations report against NZISM, HISO 10029, and the Privacy Act. Those are the frameworks that carry weight in a New Zealand audit, and they are exactly the ones an offshore tool leaves out. HISO is the cheaper win than it looks, because it is built on ISO/IEC 27002: where a finding already maps to an ISO control, the HISO mapping is largely a crosswalk. NZISM takes more work, because its controls have their own structure and verifying a mapping means reading the manual chapter by chapter.
One finding, six obligations
A single finding, "guest-executable Apex running without sharing," maps across the catalogue like this:
| Framework | Control |
|---|---|
| OWASP Top 10:2021 | A01 Broken Access Control |
| ISO/IEC 27001:2022 | A.8.3 Information access restriction |
| Security Benchmark for Salesforce | SBS-CPORTAL-001, Prevent Parameter-Based Record Access in Portal Apex |
| NZISM v3.8 | Ch.16 Authentication and Access Controls |
| HISO 10029:2022 | Access control |
| NZ Privacy Act 2020 | IPP 5, Storage and security of information |
One engineering fix. Six framework obligations the organisation can report against, each traceable to its published source.
What the mapping does not claim
A control that renders "no findings detected" is not a statement of compliance. It means the checks mapped to that control surfaced no issues at the point in time the audit ran. A configuration review is not a certification, and it is not a penetration test. It maps where findings land against a framework; it does not attest that the framework is satisfied. A compliance claim a tool cannot stand behind is a liability, not a feature.
Frequently Asked Questions
Q: Does a Salesforce security audit map to NZISM?
A: Yes. Findings can be mapped to NZISM v3.8 chapters, including Chapter 16 (Authentication and Access Controls), Section 16.6 (Event Monitoring, Logging and Auditing), Chapter 17 (Cryptography) and Chapter 14 (Software Security). The current version is NZISM v3.8, published July 2025; a mapping should be pinned to that version rather than an older one.
Q: How do I map Salesforce security to the NZ Privacy Act 2020?
A: Most Salesforce security findings relate to Information Privacy Principle 5 (storage and security of personal information). Findings about offshore data processing or cross-border integrations relate to IPP 12 (disclosure outside New Zealand). The Privacy Act applies to any organisation holding personal information, not only the regulated sectors.
Q: Is Salesforce compliant with HISO 10029?
A: Compliance is a property of your organisation and its configuration, not of Salesforce as a platform. HISO 10029:2022 is built on ISO/IEC 27002, so Salesforce findings that map to ISO 27001 controls also crosswalk to the HISO control areas. A review shows where your configuration stands against those controls; it does not certify compliance.
Q: Can a Salesforce security review produce evidence for ISO 27001 or SOC 2?
A: It can produce mapped findings against ISO/IEC 27001:2022 Annex A controls and the SOC 2 Common Criteria, which is useful input for an audit. It is not a substitute for the audit itself. The value is traceability: each finding tied to the specific control it implicates.
Key Takeaways
- Map to the frameworks that apply: for New Zealand organisations that means NZISM, HISO 10029 and the Privacy Act, alongside the universal ISO 27001, SOC 2 and OWASP.
- Exactness is the whole point: cite the control identifier, the framework version, and the official title, or the mapping is not defensible.
- Verify against the source: a mapping confirmed against the published standard catches outdated identifiers and wrong criteria before they reach a client.
- A mapping is not an attestation: it shows where findings land, not that a framework is satisfied.
What's Next?
Recommended Reading:
Action Items:
- Identify which frameworks your organisation actually reports against before commissioning any review.
- Confirm the framework versions in any compliance mapping are current (ISO 27001:2022, NZISM v3.8).
- Treat "no findings detected" as a configuration result, not a compliance statement.