Security standards
Mapping and alignment only. Quantix does not claim certification against any standard listed here.
- standards and frameworks
- 8
- control mappings
- 52
- control domains
- 12
- finding classes cross-walked
- 11
Standards
Eight references, one mapping model.
- Management system standardISO/IEC 27001ISO / IEC · 2022Requirements for establishing, operating and continually improving an information security management system.9 mapped controls
- Attestation criteriaSOC 2 TSCAICPA · TSC 2017, points of focus revised 2022Criteria used by independent CPA firms to report on controls relevant to security, availability, processing integrity, confidentiality and privacy.10 mapped controls
- Testing guideOWASP WSTGOWASP Foundation · v4.2A comprehensive methodology and test catalogue for assessing the security of web applications and web services.6 mapped controls
- Awareness & verificationOWASP Smart ContractOWASP Foundation · Top 10: 2025An awareness list of the most significant smart contract weakness classes, with companion verification and testing guidance.6 mapped controls
- Risk frameworkNIST CSF 2.0NIST · 2.0 (2024)A taxonomy of cybersecurity outcomes organised into six functions, used to understand, assess and communicate risk.7 mapped controls
- Weakness taxonomyCWEMITRE · Current listA community-developed catalogue of software and hardware weakness types with stable identifiers.6 mapped controls
- Scoring systemCVSS v4.0FIRST · 4.0 (2023)An open framework for communicating the characteristics and severity of software vulnerabilities.3 mapped controls
- Specification practiceEIP Security ConsiderationsEthereum Improvement Proposals (EIP-1) · Per proposalThe section every Ethereum Improvement Proposal must include describing the security implications of the standard.5 mapped controls
Standard detail
Purpose, structure and how each one is assessed.
Management system standard · ISO / IEC · 2022
ISO/IEC 27001:2022
Requirements for establishing, operating and continually improving an information security management system.
ISO/IEC 27001 specifies what an organisation must do to run an information security management system (ISMS): understand its context, assess and treat risk, define responsibilities, operate controls and improve them over time. Certification against it is granted by accredited certification bodies after an external audit.
The 2022 edition reorganised the reference controls in Annex A into four themes and 93 controls, aligned with ISO/IEC 27002:2022, and added controls for areas such as cloud services, configuration management, monitoring activities and secure coding.
For organisations building blockchain systems, the ISMS covers the off-chain estate around the protocol: key ceremonies, deployment pipelines, access to signing infrastructure, supplier relationships and incident management.
Clauses 4–10 and Annex A themes
- Clause 4 Context of the organisation
- Clause 5 Leadership
- Clause 6 Planning
- Clause 7 Support
- Clause 8 Operation
- Clause 9 Performance evaluation
- Clause 10 Improvement
- Annex A 5 Organisational controls (37)
- Annex A 6 People controls (8)
- Annex A 7 Physical controls (14)
- Annex A 8 Technological controls (34)
How Quantix relates to it
Quantix assesses the technical controls of a client environment against selected Annex A controls and records evidence a certification audit can reuse. Quantix does not certify organisations and is not a certification body.
Assessment process
- 01Agree the Annex A controls relevant to the systems in scope, usually the technological theme plus incident and supplier controls.
- 02Review design documents, configurations and access lists for each control; interview the owners.
- 03Test operating effectiveness where possible: attempt privileged actions, inspect logs, trace a change from request to deployment.
- 04Rate each control on the Quantix maturity scale and record gaps with remediation guidance.
Technical deliverables
- Control-by-control gap assessment against the selected Annex A controls
- Evidence register cross-referenced to control identifiers
- Prioritised remediation plan with owners
- Maturity rating per control domain
Evidence collected
- Access-control lists and privileged-role inventories
- Key-management procedures and ceremony records
- Change and deployment logs from the CI/CD pipeline
- Monitoring rules, alert records and on-call runbooks
- Supplier inventory with security review records
Mapped controls (9)
Evidence and deliverables for each control are listed in the control matrix.
A.5.15
Access control
Rules for who may access deployment, signing and admin systems, and whether those rules are enforced in practice.
Access control · Penetration Testing · Security Advisory
A.8.2
Privileged access rights
Who holds protocol admin keys, multisig signer seats and cloud root access; how grants are approved and revoked.
Access control · Smart Contract Auditing · Security Advisory · Penetration Testing
A.8.24
Use of cryptography
Key generation, storage (HSM, MPC, hardware wallets), rotation and the signing schemes used on- and off-chain.
Cryptography & keys · Security Advisory · Penetration Testing
A.8.25
Secure development life cycle
Whether threat modelling, review, testing and audit gates exist before each release of contract and backend code.
Secure development · Smart Contract Auditing · Security Advisory
A.8.8
Management of technical vulnerabilities
How findings from audits, bug reports and dependency alerts are triaged, fixed and verified within agreed timeframes.
Vulnerability management · Smart Contract Auditing · Penetration Testing
A.8.16
Monitoring activities
Coverage of on-chain and infrastructure monitoring for privileged operations, upgrades and anomalous flows.
Monitoring & detection · Continuous Monitoring
A.5.26
Response to information security incidents
Incident runbooks for exploits, key compromise and front-end compromise, including pause and communication procedures.
Incident response · Incident Response · Security Advisory
A.5.21
Managing information security in the ICT supply chain
Dependencies on oracles, bridges, RPC providers, libraries and front-end packages, and how their risk is assessed.
Supply chain · Security Advisory · Threat Intelligence
A.5.31
Legal, statutory, regulatory and contractual requirements
Whether obligations such as sanctions screening and travel-rule data exchange are identified, owned and reflected in transaction-monitoring controls.
Governance & risk · AML & Compliance · Security Advisory
Official reference: ISO/IEC 27001:2022 — ISO catalogue(opens in a new tab)
Attestation criteria · AICPA · TSC 2017, points of focus revised 2022
SOC 2 — Trust Services Criteria
Criteria used by independent CPA firms to report on controls relevant to security, availability, processing integrity, confidentiality and privacy.
A SOC 2 report is an attestation issued by a licensed CPA firm on a service organisation’s controls, measured against the AICPA Trust Services Criteria. A Type 1 report covers the design of controls at a point in time; a Type 2 report also covers their operating effectiveness over a period.
Security is covered by the Common Criteria and is always in scope; availability, processing integrity, confidentiality and privacy are added when relevant to the service.
Custodians, exchanges and infrastructure providers in the blockchain sector often prepare for SOC 2. Technical assessments can supply evidence for the criteria that concern logical access, system operations and change management.
Trust Services categories and Common Criteria series
- Security (Common Criteria)
- Availability
- Processing Integrity
- Confidentiality
- Privacy
- CC1 Control environment
- CC2 Communication and information
- CC3 Risk assessment
- CC4 Monitoring activities
- CC5 Control activities
- CC6 Logical and physical access controls
- CC7 System operations
- CC8 Change management
- CC9 Risk mitigation
How Quantix relates to it
Quantix is not a CPA firm and does not issue SOC 2 reports. Quantix technical assessments test controls mapped to the criteria and produce evidence that a client and its auditor can use during readiness and the attestation period.
Assessment process
- 01Map the client’s system description to the criteria in scope and identify the technical controls behind them.
- 02Test logical access, key management, change management and monitoring controls on the actual systems.
- 03Document exceptions with root cause, affected period and remediation status.
- 04Provide a readiness view per criterion so the client can prioritise before the audit period begins.
Technical deliverables
- Readiness assessment per criterion in scope
- Technical test results with exceptions
- Evidence package referenced to criteria
- Remediation roadmap ahead of the observation period
Evidence collected
- Access provisioning and de-provisioning records
- Change tickets traced to deployments
- Monitoring and alert response records
- Vendor risk assessments
- Backup and recovery test records
Mapped controls (10)
Evidence and deliverables for each control are listed in the control matrix.
CC6.1
Logical access security over protected information assets
Authentication, authorisation and segmentation around signing services, admin consoles and production databases.
Access control · Penetration Testing
CC6.3
Authorising, modifying and removing access based on roles
Role-based access for operators and approvers, including policy-engine quorums for custody transactions.
Access control · Penetration Testing · Security Advisory
CC7.1
Detection of configuration changes and new vulnerabilities
Detection of configuration drift and newly disclosed vulnerabilities in dependencies, nodes and contracts.
Vulnerability management · Penetration Testing · Continuous Monitoring
CC7.2
Monitoring system components for anomalies
Monitoring of privileged contract calls, treasury movements and infrastructure anomalies with defined thresholds.
Monitoring & detection · Continuous Monitoring · Threat Intelligence
CC7.4
Responding to identified security incidents
Containment steps (pause, key rotation, front-end takedown), communication and evidence preservation.
Incident response · Incident Response
CC8.1
Change management
Whether contract upgrades and backend releases are authorised, reviewed, tested and approved before deployment.
Secure development · Smart Contract Auditing · Security Advisory
CC9.2
Vendor and business partner risk
Risk assessment of custodians, oracle providers, bridge operators and other critical vendors.
Supply chain · Security Advisory · Threat Intelligence
A1.2
Recovery infrastructure and backups
Backup, recovery and key-recovery procedures for signing infrastructure and critical services.
Resilience · Security Advisory
PI1
Processing integrity: complete, valid, accurate and timely processing
Completeness and accuracy of the liabilities snapshot behind a reserves attestation: every account included, balances correct, exclusion rules documented.
Data integrity · Proof of Reserves
C1.1
Identifying and maintaining confidential information
Handling of investigation case files, screening results and requests from authorities: who can see them and how long they are kept.
Access control · AML & Compliance · Incident Response
Official reference: AICPA — 2017 Trust Services Criteria (revised points of focus, 2022)(opens in a new tab)
Testing guide · OWASP Foundation · v4.2
OWASP Web Security Testing Guide
A comprehensive methodology and test catalogue for assessing the security of web applications and web services.
The Web Security Testing Guide describes how to test web applications: what to look for, how to test it, and what tools help. Each test has a stable identifier such as WSTG-ATHN or WSTG-INPV followed by a number, which makes results traceable.
Most losses involving decentralised systems pass through web infrastructure at some point: wallet connection flows, transaction-building APIs, admin dashboards and front-end supply chains. The WSTG provides the baseline for testing these components.
Quantix extends the guide with Web3-specific cases, such as transaction-construction integrity, signature-request rendering and RPC endpoint hardening.
Testing categories
- WSTG-INFO Information gathering
- WSTG-CONF Configuration and deployment management
- WSTG-IDNT Identity management
- WSTG-ATHN Authentication
- WSTG-ATHZ Authorisation
- WSTG-SESS Session management
- WSTG-INPV Input validation
- WSTG-ERRH Error handling
- WSTG-CRYP Weak cryptography
- WSTG-BUSL Business logic
- WSTG-CLNT Client-side
- WSTG-APIT API testing
How Quantix relates to it
Quantix penetration tests follow the WSTG categories as their baseline test plan and reference WSTG identifiers in findings, alongside Web3-specific test cases.
Assessment process
- 01Agree scope and rules of engagement in writing: hosts, APIs, test accounts, timing and contacts.
- 02Map the application and its trust boundaries, including wallet and signing flows.
- 03Execute WSTG categories relevant to the stack, plus Web3 cases (transaction tampering, signature rendering, RPC abuse).
- 04Validate findings, rate severity and retest after remediation.
Technical deliverables
- Penetration test report with WSTG references per finding
- Reproduction steps and evidence
- Risk-ranked remediation plan
- Retest report
Evidence collected
- Request/response captures
- Screenshots and screen recordings
- Tool output with timestamps
- Configuration excerpts
Mapped controls (6)
Evidence and deliverables for each control are listed in the control matrix.
WSTG-ATHN
Authentication testing
Login, wallet-signature authentication (e.g. sign-in messages), session binding and authentication bypass.
Application security · Penetration Testing
WSTG-ATHZ-02
Bypassing authorisation schema
Whether API endpoints and admin functions enforce authorisation server-side for every role.
Access control · Penetration Testing
WSTG-INPV
Input validation testing
Injection and validation flaws in APIs that build or relay transactions, including parameter tampering.
Application security · Penetration Testing
WSTG-BUSL
Business logic testing
Abuse of workflow assumptions: altering amounts, recipients or chain IDs between display and signing.
Application security · Penetration Testing
WSTG-CLNT
Client-side testing
DOM injection, script integrity, third-party scripts and dependency tampering in dApp front ends.
Supply chain · Penetration Testing · Threat Intelligence
WSTG-CONF
Configuration and deployment management
TLS, security headers, exposed admin interfaces, RPC methods enabled on public endpoints, cloud storage exposure.
Resilience · Penetration Testing
Official reference: OWASP Web Security Testing Guide(opens in a new tab)
Awareness & verification · OWASP Foundation · Top 10: 2025
OWASP Smart Contract Top 10 and Smart Contract Security project
An awareness list of the most significant smart contract weakness classes, with companion verification and testing guidance.
The OWASP Smart Contract Top 10 ranks the weakness classes most associated with losses in smart contracts. It is an awareness document: it tells teams where to look first, not everything they must check.
The wider OWASP Smart Contract Security project adds a verification standard (SCSVS), a testing guide (SCSTG) and a weakness enumeration (SCWE) for systematic review.
Quantix uses the Top 10 as a shared vocabulary in reports and maps every finding to its closest entry, while the review itself covers the protocol’s full specification.
Smart Contract Top 10 (2025)
- SC01 Access control vulnerabilities
- SC02 Price oracle manipulation
- SC03 Logic errors
- SC04 Lack of input validation
- SC05 Reentrancy attacks
- SC06 Unchecked external calls
- SC07 Flash loan attacks
- SC08 Integer overflow and underflow
- SC09 Insecure randomness
- SC10 Denial of service attacks
How Quantix relates to it
Every Quantix smart contract finding is mapped to its nearest Top 10 entry and CWE, so results can be compared across reports and with other reviewers.
Assessment process
- 01Reconstruct the protocol’s intended behaviour and invariants from specifications and code.
- 02Review every in-scope line with the Top 10 classes as a minimum checklist.
- 03Run static analysis and invariant fuzzing targeted at the classes most relevant to the design.
- 04Validate findings with proof-of-concept tests and map each to its Top 10 entry and CWE.
Technical deliverables
- Research assessment report with Top 10 and CWE mapping per finding
- Proof-of-concept tests for material findings
- Fix review against the remediation commit
Evidence collected
- Commit references
- Proof-of-concept test files
- Fuzzing harnesses and corpora
- Static analysis triage notes
Mapped controls (6)
Evidence and deliverables for each control are listed in the control matrix.
SC01:2025
Access control vulnerabilities
Every privileged function, initializer and role grant; who can call it and with what delay.
Smart contract security · Smart Contract Auditing · Formal Verification
SC02:2025
Price oracle manipulation
Price sources, aggregation, staleness and deviation checks; cost to move each price within one block.
Smart contract security · Smart Contract Auditing
SC05:2025
Reentrancy attacks
External calls, callbacks and hooks; state written after interactions; view functions read mid-call.
Smart contract security · Smart Contract Auditing
SC06:2025
Unchecked external calls
Low-level calls and token transfers whose return values or revert behaviour are ignored.
Smart contract security · Smart Contract Auditing
SC07:2025
Flash loan attacks
Logic that assumes balances, prices or voting power cannot change within one transaction.
Smart contract security · Smart Contract Auditing · Formal Verification
SC10:2025
Denial of service attacks
Unbounded loops, griefing vectors, blocking queues and dependencies whose failure halts the protocol.
Smart contract security · Smart Contract Auditing
Official reference: OWASP Smart Contract Top 10(opens in a new tab)
Risk framework · NIST · 2.0 (2024)
NIST Cybersecurity Framework 2.0
A taxonomy of cybersecurity outcomes organised into six functions, used to understand, assess and communicate risk.
CSF 2.0 organises cybersecurity outcomes into six functions: Govern, Identify, Protect, Detect, Respond and Recover. Each function is divided into categories and subcategories that describe outcomes rather than prescribe controls.
The 2.0 release added the Govern function, which covers organisational context, risk strategy, roles and responsibilities, policy, oversight and supply-chain risk management.
Organisations use Current and Target Profiles to describe where they are and where they want to be, and Tiers (Partial, Risk Informed, Repeatable, Adaptive) to characterise the rigour of their practices.
Functions and selected categories
- GV Govern — GV.OC, GV.RM, GV.RR, GV.PO, GV.OV, GV.SC
- ID Identify — ID.AM, ID.RA, ID.IM
- PR Protect — PR.AA, PR.AT, PR.DS, PR.PS, PR.IR
- DE Detect — DE.CM, DE.AE
- RS Respond — RS.MA, RS.AN, RS.CO, RS.MI
- RC Recover — RC.RP, RC.CO
How Quantix relates to it
Quantix advisory engagements express findings as Current and Target Profiles across the CSF functions, which gives boards and auditors a familiar structure for technical results.
Assessment process
- 01Establish the organisational context and the systems that hold or move value.
- 02Assess current outcomes per category using interviews, documents and technical testing.
- 03Agree a Target Profile with leadership based on risk appetite.
- 04Produce a prioritised plan that closes the gap, mapped to Quantix services where testing is needed.
Technical deliverables
- Current and Target Profiles
- Gap analysis per function
- Prioritised security roadmap
Evidence collected
- Policy documents
- Interview notes
- Technical test results
- Asset and dependency inventories
Mapped controls (7)
Evidence and deliverables for each control are listed in the control matrix.
GV.SC
Cybersecurity supply chain risk management
How oracle, bridge, RPC, custody and library dependencies are selected, assessed and monitored.
Supply chain · Security Advisory · Threat Intelligence
ID.RA
Risk assessment
Threat models for the protocol and its operations, and how they are kept current.
Governance & risk · Security Advisory · Smart Contract Auditing
PR.AA
Identity management, authentication and access control
Authentication of operators and signers, and least-privilege access to production and signing systems.
Access control · Penetration Testing · Security Advisory
PR.PS
Platform security
Hardening of nodes, CI/CD, build reproducibility and deployment of verified contract bytecode.
Secure development · Penetration Testing · Smart Contract Auditing
DE.CM
Continuous monitoring
Monitoring of contract events, privileged actions, infrastructure and external threat indicators.
Monitoring & detection · Continuous Monitoring · Threat Intelligence
DE.AE
Adverse event analysis
How alerts on suspicious flows (mixers, sanctioned addresses, peel chains, bridge hops) are correlated, analysed and escalated.
Monitoring & detection · AML & Compliance · Continuous Monitoring · Threat Intelligence
RS.MA
Incident management
Triage, escalation, containment authority and coordination during an on-chain incident.
Incident response · Incident Response
Official reference: NIST Cybersecurity Framework 2.0 (NIST CSWP 29)(opens in a new tab)
Weakness taxonomy · MITRE · Current list
Common Weakness Enumeration
A community-developed catalogue of software and hardware weakness types with stable identifiers.
CWE gives each weakness type a stable identifier and organises them in a hierarchy of pillars, classes, bases and variants. Views such as Research Concepts (CWE-1000) and Software Development (CWE-699) arrange the same entries for different audiences.
Mapping findings to CWE makes them comparable across tools, reports and organisations, and connects them to mitigation guidance maintained by the community.
Smart contract weaknesses do not always have a precise CWE; in those cases Quantix records the closest applicable entry and states the mapping as approximate.
Hierarchy and commonly used views
- Pillar
- Class
- Base
- Variant
- Composite and chain
- View CWE-1000 Research Concepts
- View CWE-699 Software Development
- CWE Top 25 Most Dangerous Software Weaknesses
How Quantix relates to it
Every Quantix finding carries a CWE identifier where one applies, used for aggregation in the intelligence platform and for comparison with other sources.
Assessment process
- 01Classify each validated finding by root cause.
- 02Select the most specific applicable CWE entry.
- 03Record approximate mappings explicitly.
- 04Aggregate CWE data across assessments for trend analysis.
Technical deliverables
- CWE identifier per finding
- Weakness trend analysis across engagements
Evidence collected
- Root-cause notes per finding
- Mapping rationale for approximate entries
Mapped controls (6)
Evidence and deliverables for each control are listed in the control matrix.
CWE-284
Improper access control
Missing or incorrect restrictions on privileged operations, on-chain and off-chain.
Access control · Smart Contract Auditing · Penetration Testing
CWE-841
Improper enforcement of behavioural workflow
Reentrancy and ordering issues where state transitions can be interleaved.
Smart contract security · Smart Contract Auditing
CWE-1339
Insufficient precision or accuracy of a real number
Rounding direction, precision loss and share-accounting edge cases.
Smart contract security · Smart Contract Auditing · Formal Verification
CWE-347
Improper verification of cryptographic signature
Signature verification, domain separation and replay protection in permits, bridges and meta-transactions.
Cryptography & keys · Smart Contract Auditing · Penetration Testing
CWE-252
Unchecked return value
Ignored return values from token transfers and low-level calls.
Smart contract security · Smart Contract Auditing
CWE-345
Insufficient verification of data authenticity
Whether users can verify inclusion of their balance and whether the published Merkle root matches the attested snapshot; oracle data authenticity.
Data integrity · Proof of Reserves · Smart Contract Auditing
Official reference: MITRE CWE(opens in a new tab)
Scoring system · FIRST · 4.0 (2023)
Common Vulnerability Scoring System v4.0
An open framework for communicating the characteristics and severity of software vulnerabilities.
CVSS v4.0 describes a vulnerability with a vector string built from metric groups and derives a score from 0 to 10. Scores are labelled by the metric groups used: CVSS-B (Base only), CVSS-BT (with Threat), CVSS-BE (with Environmental) and CVSS-BTE.
Version 4.0 introduced Attack Requirements (AT), separated impacts on the vulnerable system from impacts on subsequent systems, and added Supplemental metrics such as Automatable and Recovery that inform response without changing the score.
CVSS was designed for conventional software and services. It fits off-chain findings well; for on-chain logic flaws its impact metrics do not capture loss of funds directly, so Quantix uses its own impact × likelihood rubric for severity and records a CVSS vector as supplementary information.
Metric groups
- Base — Exploitability: AV, AC, AT, PR, UI
- Base — Vulnerable system impact: VC, VI, VA
- Base — Subsequent system impact: SC, SI, SA
- Threat — Exploit Maturity (E)
- Environmental — CR, IR, AR and modified base metrics
- Supplemental — Safety, Automatable, Recovery, Value Density, Response Effort, Provider Urgency
How Quantix relates to it
Quantix penetration test findings carry a CVSS v4.0 vector and score computed with the FIRST specification; smart contract findings carry a vector for reference alongside the Quantix severity rubric.
Assessment process
- 01Rate exploitability and impact from the validated proof of concept, not from theory.
- 02Record the Base vector; add Threat and Environmental metrics when the client supplies context.
- 03Compute the score with the FIRST calculator and record the nomenclature (CVSS-B, CVSS-BT…).
- 04Explain any difference between the CVSS score and the Quantix severity.
Technical deliverables
- CVSS v4.0 vector and score per off-chain finding
- Rationale for each metric value
Evidence collected
- Proof-of-concept results
- Environment description supplied by the client
Mapped controls (3)
Evidence and deliverables for each control are listed in the control matrix.
Base metrics
Exploitability and impact characterisation
Attack vector, complexity, requirements, privileges and user interaction observed during testing.
Vulnerability management · Penetration Testing
Environmental metrics
Environment-specific severity
Confidentiality, integrity and availability requirements of the affected asset in the client’s context.
Governance & risk · Penetration Testing · Security Advisory
Supplemental metrics
Response-relevant attributes
Whether exploitation is automatable and how recoverable the affected component is.
Incident response · Penetration Testing · Incident Response
Official reference: FIRST — CVSS v4.0 Specification(opens in a new tab)
Specification practice · Ethereum Improvement Proposals (EIP-1) · Per proposal
EIP Security Considerations
The section every Ethereum Improvement Proposal must include describing the security implications of the standard.
EIP-1 requires every proposal to include a Security Considerations section that discusses the security implications relevant to the change. For token, vault, signature and proxy standards, these sections record pitfalls that implementers repeatedly get wrong.
Examples include the approval race described with ERC-20, domain separation in EIP-712, replay protection through chain ID in EIP-155, permit front-running in EIP-2612, rounding and inflation risks in ERC-4626, and storage-slot conventions in ERC-1967.
Quantix reviews each implementation against the security considerations of every standard it implements or integrates with, and treats deviations as findings or documented assumptions.
Standards frequently reviewed
- ERC-20
- EIP-155
- EIP-712
- EIP-1271
- ERC-1967
- EIP-2612
- ERC-4337
- ERC-4626
How Quantix relates to it
Standards conformance and their security considerations are a fixed part of every Quantix smart contract assessment.
Assessment process
- 01List every standard the system implements or depends on, including token behaviours of integrated assets.
- 02Check conformance and the specific risks listed in each standard’s Security Considerations section.
- 03Test non-standard token behaviours (fee-on-transfer, rebasing, missing return values) against integrations.
- 04Record deviations as findings or explicit assumptions.
Technical deliverables
- Standards conformance checklist
- Findings for deviations
- Integration assumptions register
Evidence collected
- Interface conformance tests
- Token behaviour test matrix
Mapped controls (5)
Evidence and deliverables for each control are listed in the control matrix.
EIP-712
Typed structured data signing
Domain separator contents (chain ID, verifying contract), type hashes and replay protection.
Cryptography & keys · Smart Contract Auditing
EIP-2612
Permit approvals
Nonce handling, deadlines and integrations that assume permit cannot be front-run.
Smart contract security · Smart Contract Auditing
ERC-4626
Tokenised vaults
Rounding direction in conversions and protection against share-price inflation by donation.
Smart contract security · Smart Contract Auditing · Formal Verification
ERC-1967
Proxy storage slots
Implementation and admin slots, initializer protection and upgrade authorisation.
Secure development · Smart Contract Auditing
EIP-155
Chain ID replay protection
Transaction and message signing across networks that share contract addresses.
Cryptography & keys · Smart Contract Auditing · Penetration Testing
Official reference: EIP-1: EIP Purpose and Guidelines(opens in a new tab)
Control matrix
From standard control to deliverable.
Showing 12 of 52 control mappings
ISO/IEC 27001A.5.15
Access control
Rules for who may access deployment, signing and admin systems, and whether those rules are enforced in practice.
- Evidence
- Role inventory; Access review records; Selected access requests traced end to end
- Deliverable
- Gap assessment, access-control section
- Domain · services
- Access control · Penetration Testing, Security Advisory
ISO/IEC 27001A.8.2
Privileged access rights
Who holds protocol admin keys, multisig signer seats and cloud root access; how grants are approved and revoked.
- Evidence
- Signer list per multisig; Proxy admin and owner addresses; Cloud IAM export
- Deliverable
- Privileged-access register with findings
- Domain · services
- Access control · Smart Contract Auditing, Security Advisory, Penetration Testing
ISO/IEC 27001A.8.24
Use of cryptography
Key generation, storage (HSM, MPC, hardware wallets), rotation and the signing schemes used on- and off-chain.
- Evidence
- Key-management policy; Ceremony transcripts; Signer device inventory
- Deliverable
- Key-management review
- Domain · services
- Cryptography & keys · Security Advisory, Penetration Testing
ISO/IEC 27001A.8.25
Secure development life cycle
Whether threat modelling, review, testing and audit gates exist before each release of contract and backend code.
- Evidence
- Release checklist; Pull-request review history; Test and fuzzing coverage reports
- Deliverable
- SDLC maturity rating and recommendations
- Domain · services
- Secure development · Smart Contract Auditing, Security Advisory
ISO/IEC 27001A.8.8
Management of technical vulnerabilities
How findings from audits, bug reports and dependency alerts are triaged, fixed and verified within agreed timeframes.
- Evidence
- Finding tracker export; Fix commits linked to findings; Dependency alert history
- Deliverable
- Remediation analysis in the assessment report
- Domain · services
- Vulnerability management · Smart Contract Auditing, Penetration Testing
ISO/IEC 27001A.8.16
Monitoring activities
Coverage of on-chain and infrastructure monitoring for privileged operations, upgrades and anomalous flows.
- Evidence
- Monitoring rule set; Alert routing configuration; Recent alerts with response notes
- Deliverable
- Monitoring design review
- Domain · services
- Monitoring & detection · Continuous Monitoring
ISO/IEC 27001A.5.26
Response to information security incidents
Incident runbooks for exploits, key compromise and front-end compromise, including pause and communication procedures.
- Evidence
- Incident runbooks; Exercise records; Post-incident reviews
- Deliverable
- Incident-readiness assessment
- Domain · services
- Incident response · Incident Response, Security Advisory
ISO/IEC 27001A.5.21
Managing information security in the ICT supply chain
Dependencies on oracles, bridges, RPC providers, libraries and front-end packages, and how their risk is assessed.
- Evidence
- Supplier and dependency inventory; Pinned versions and lockfiles; Provider risk notes
- Deliverable
- Dependency risk register
- Domain · services
- Supply chain · Security Advisory, Threat Intelligence
ISO/IEC 27001A.5.31
Legal, statutory, regulatory and contractual requirements
Whether obligations such as sanctions screening and travel-rule data exchange are identified, owned and reflected in transaction-monitoring controls.
- Evidence
- Obligations register; Screening configuration; Control ownership matrix
- Deliverable
- Compliance-control gap assessment
- Domain · services
- Governance & risk · AML & Compliance, Security Advisory
SOC 2 TSCCC6.1
Logical access security over protected information assets
Authentication, authorisation and segmentation around signing services, admin consoles and production databases.
- Evidence
- Access-control configuration; MFA enforcement evidence; Network segmentation diagrams
- Deliverable
- Access-control test results
- Domain · services
- Access control · Penetration Testing
SOC 2 TSCCC6.3
Authorising, modifying and removing access based on roles
Role-based access for operators and approvers, including policy-engine quorums for custody transactions.
- Evidence
- Role definitions; Joiner, mover and leaver records; Approval-quorum configuration
- Deliverable
- Role and approval review
- Domain · services
- Access control · Penetration Testing, Security Advisory
SOC 2 TSCCC7.1
Detection of configuration changes and new vulnerabilities
Detection of configuration drift and newly disclosed vulnerabilities in dependencies, nodes and contracts.
- Evidence
- Scanning schedules; Dependency alert triage records; Configuration baselines
- Deliverable
- Vulnerability management review
- Domain · services
- Vulnerability management · Penetration Testing, Continuous Monitoring
Coverage by domain
Where each standard contributes mappings. Gaps are expected: a testing guide and a management system standard cover different ground.
| Standard | Governance & risk | Access control | Cryptography & keys | Secure development | Smart contract security | Application security | Vulnerability management | Monitoring & detection | Incident response | Supply chain | Data integrity | Resilience | Total |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ISO/IEC 27001 | 1 | 2 | 1 | 1 | 0 | 0 | 1 | 1 | 1 | 1 | 0 | 0 | 9 |
| SOC 2 TSC | 0 | 3 | 0 | 1 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 10 |
| OWASP WSTG | 0 | 1 | 0 | 0 | 0 | 3 | 0 | 0 | 0 | 1 | 0 | 1 | 6 |
| OWASP Smart Contract | 0 | 0 | 0 | 0 | 6 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 6 |
| NIST CSF 2.0 | 1 | 1 | 0 | 1 | 0 | 0 | 0 | 2 | 1 | 1 | 0 | 0 | 7 |
| CWE | 0 | 1 | 1 | 0 | 3 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 6 |
| CVSS v4.0 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 3 |
| EIP Security Considerations | 0 | 0 | 2 | 1 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 5 |
| All standards | 3 | 8 | 4 | 4 | 11 | 3 | 3 | 4 | 4 | 4 | 2 | 2 | 52 |
Maturity model
A five-level scale for the systems we assess.
| Level | Secure development | Key management | Governance & upgrades | Monitoring | Incident response |
|---|---|---|---|---|---|
| L1InitialSecurity work happens ad hoc and depends on individuals. | |||||
| L2DevelopingBasic practices exist but are applied inconsistently. | |||||
| L3DefinedPractices are documented and applied to every release. | |||||
| L4ManagedPractices are measured and gaps are closed to agreed timeframes. | |||||
| L5OptimisedSecurity is continuous, verified and transparent. |
Self-check
Select the statement that best describes a system in each column. 0 of 5 domains rated.
- Secure developmentNot rated
- Key managementNot rated
- Governance & upgradesNot rated
- MonitoringNot rated
- Incident responseNot rated
Crosswalk
One finding, four vocabularies.
- CWE
CWE-841 Improper Enforcement of Behavioral Workflow
CWE-1265 Unintended Reentrant Invocation of Non-reentrant Code Via Nested Calls
- OWASP Smart Contract Top 10
- SC05:2025 Reentrancy attacks
- Example CVSS v4.0 base vector
- CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
- Quantix severity guidance
- High to Critical when funds can be withdrawn twice; Medium when limited to specific token types.
- Mapping note
- Attack Requirements (AT:P) reflect that a callback-capable token or receiver must be involved.
- OWASP Smart Contract Top 10
- SC01:2025 Access control vulnerabilities
- Example CVSS v4.0 base vector
- CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
- Quantix severity guidance
- Critical when an unprivileged caller can move funds or upgrade code; High for fee or parameter control.
- Mapping note
- A missing modifier on a privileged setter is the most common instance.
- CWE
CWE-345 Insufficient Verification of Data Authenticity (approximate)
- OWASP Smart Contract Top 10
- SC02:2025 Price oracle manipulation
- Example CVSS v4.0 base vector
- CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
- Quantix severity guidance
- Depends on the cost to move the price against the value extractable; often High.
- Mapping note
- No CWE describes economic price manipulation precisely; the mapping is approximate.
- CWE
CWE-682 Incorrect Calculation (approximate)
- OWASP Smart Contract Top 10
- SC07:2025 Flash loan attacks
- Example CVSS v4.0 base vector
- CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
- Quantix severity guidance
- Rated by the underlying flaw the loan amplifies, typically High or Critical.
- Mapping note
- Flash loans remove capital requirements; the root cause is usually a price, vote or balance assumption.
- OWASP Smart Contract Top 10
- SC08:2025 Integer overflow and underflow
- Example CVSS v4.0 base vector
- CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
- Quantix severity guidance
- Medium for systematic value leakage; Critical when combined with share-price inflation.
- Mapping note
- The Top 10 entry covers arithmetic errors broadly; rounding direction is the usual root cause in vaults.
06
Unchecked external call
- CWE
CWE-252 Unchecked Return Value
- OWASP Smart Contract Top 10
- SC06:2025 Unchecked external calls
- Example CVSS v4.0 base vector
- CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N
- Quantix severity guidance
- Medium in most cases; High when accounting proceeds after a silent transfer failure.
- Mapping note
- Tokens that return false instead of reverting are the typical trigger.
- CWE
CWE-294 Authentication Bypass by Capture-replay
CWE-347 Improper Verification of Cryptographic Signature
- OWASP Smart Contract Top 10
- Not listed separately; reviewed with SC01 and SC04
- Example CVSS v4.0 base vector
- CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
- Quantix severity guidance
- High when a signature can be reused on another chain or contract to move funds.
- Mapping note
- Missing chain ID or verifying-contract binding in the EIP-712 domain is the usual cause.
- CWE
CWE-665 Improper Initialization
- OWASP Smart Contract Top 10
- Not listed separately; reviewed with SC01
- Example CVSS v4.0 base vector
- CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N
- Quantix severity guidance
- Critical when an attacker can initialise or upgrade the implementation; Low for missing storage gaps.
- Mapping note
- Covers unprotected initializers, storage collisions and unauthorised upgrade paths.
09
Business logic error
- CWE
CWE-840 Business Logic Errors (category)
- OWASP Smart Contract Top 10
- SC03:2025 Logic errors
- Example CVSS v4.0 base vector
- CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
- Quantix severity guidance
- Rated case by case against the protocol specification.
- Mapping note
- CWE-840 is a category, so findings also carry a more specific base entry when one fits.
10
Denial of service
- CWE
CWE-400 Uncontrolled Resource Consumption
- OWASP Smart Contract Top 10
- SC10:2025 Denial of service attacks
- Example CVSS v4.0 base vector
- CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
- Quantix severity guidance
- Medium when temporary; High when funds are locked or liquidations blocked.
- Mapping note
- Unbounded loops over user-controlled arrays and blocking queues are common sources.
11
Insecure randomness
- CWE
CWE-330 Use of Insufficiently Random Values
- OWASP Smart Contract Top 10
- SC09:2025 Insecure randomness
- Example CVSS v4.0 base vector
- CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
- Quantix severity guidance
- High when outcomes with value depend on block data a validator or searcher can influence.
- Mapping note
- Block hashes, timestamps and prevrandao are observable or influenceable before inclusion.
Questions about mappings.
How Quantix runs its own work is set out in the assurance framework.
No. This page describes how Quantix assessments map to the standards and what evidence they produce. Quantix does not hold or claim any certification, attestation or accreditation. ISO/IEC 27001 certificates are issued by accredited certification bodies and SOC 2 reports by licensed CPA firms.
It can supply evidence. The evidence register cross-references every item to the control or criterion it supports, so the client and their auditor can decide what to reuse. The audit itself, and the opinion it produces, remain the auditor’s.
CVSS v4.0 is the common language for off-chain vulnerabilities, so web and infrastructure findings carry a vector and score. Its impact metrics do not express loss of funds directly, so smart contract findings are rated on the Quantix impact × likelihood rubric, with a CVSS vector recorded for reference. Any difference between the two is explained in the finding.
Some smart contract weaknesses, such as economic price manipulation, have no exact CWE entry. Quantix records the closest entry and marks it approximate so aggregated statistics are not mistaken for an exact classification.
No. It is the scale Quantix uses to rate the systems it assesses. How Quantix runs its own work is described in the assurance framework.
Map an assessment to your framework.
Tell us which standard your auditors or board work from, and we will scope an assessment whose evidence fits it.