§Methodology
V-Standard 2026.3
An open methodology for remote security assessment. Its 60 check groups describe assessment areas; specific tests depend on technologies, access and agreed scope. Results are recorded in the report and public certificate record.
Edition 2026.3 · Effective from 2026-07-01
How the methodology is built
Check groups, not tool output
Each check group aggregates multiple automated tests and, where the level requires, expert scenarios. A group passes only when every test in it passes or is formally not applicable.
Methods are declared
Every check states its method: automated, SCA/CVE matching, secret scan, SAST, manual scenario, evidence review, or a combination. The method is printed on the Trust Page.
Scope is fixed before testing
Components, domains, environments and exclusions are agreed in writing and cannot be narrowed after a finding.
Evidence is kept, details are not published
We store the evidence for every result. Trust Pages carry only a safe public summary — never vulnerability details, secrets, private URLs or code.
Versioned
The catalogue is versioned by edition. A certificate always names the edition it was verified against.
Catalogue of checks
Sixty check groups. The letter and number of a check are stable across editions and appear on every Trust Page. Levels: V1 covers domain A; V2 adds B; V3 adds C; V4 adds D and E. Domain F is an add-on to any level.
See the automated coverage behind these perimeter groups →
No matching checks. Change the query or domain.
External perimeter
Everything an attacker can reach without credentials: domains, TLS, DNS, mail authentication, exposed services and the software versions behind them.
- A01TLS configuration and certificate validity
Supported protocol versions and cipher suites, certificate chain, expiry, revocation information, key strength and known TLS weaknesses on every public endpoint in scope.
- A02HTTPS enforcement and HSTS
Plain-HTTP requests are redirected to HTTPS, HSTS is present with an adequate lifetime, and no content in scope is served over an unencrypted channel.
- A03DNS configuration and zone hygiene
Authoritative servers, DNSSEC where applicable, dangling records that allow sub-domain takeover, zone transfer exposure and consistency between public and expected records.
- A04Email authentication (SPF, DKIM, DMARC)
Sender authentication for the product's domains: SPF syntax and scope, DKIM signing, DMARC policy and reporting, MTA-STS where present.
- A05HTTP security headers
Content-Security-Policy, frame protection, content-type sniffing, referrer policy, permissions policy and cache directives on sensitive responses.
- A06Exposed services and open ports
Inventory of listening services on the public perimeter, unexpected management ports, databases or message brokers reachable from the internet.
- A07Known-vulnerable software versions
Identified server software, frameworks and components on the perimeter are matched against published vulnerability records (CVE/NVD, CISA KEV, vendor advisories).
- A08Administrative interfaces and default credentials
Administration panels, monitoring dashboards and management consoles reachable from the internet; default or vendor credentials on any such interface.
- A09Information disclosure
Version banners, directory listings, debug endpoints, source-control folders, environment files, backups and stack traces reachable on the perimeter.
- A11Redirects and mixed content
Open redirects, insecure downgrade paths and mixed-content resources on pages in scope.
- A12Vulnerability disclosure channel
A published way to report a vulnerability (security.txt or equivalent) that reaches a responsible person and is answered.
Application and API
How the product authenticates, authorises and isolates its users, and how it handles hostile input across the web application and its APIs.
- B01Authentication
Credential policy, multi-factor availability, brute-force and credential-stuffing protection, safe handling of failed logins and enumeration.
- B02Session management
Session identifier generation, rotation on privilege change, expiry, revocation on logout and concurrent-session handling.
- B03Authorisation and roles
Role model enforcement on every function and object: horizontal and vertical privilege escalation, insecure direct object references, mass assignment.
- B04Tenant and data isolation
Separation of data between organisations or accounts in a multi-tenant product: queries, storage, caches, background jobs and exports.
- B05Input handling and injection
Server-side injection classes — SQL, NoSQL, command, template, path traversal, server-side request forgery, XML external entities — across the endpoints in scope.
- B06Client-side security
Cross-site scripting (reflected, stored, DOM-based), cross-site request forgery, clickjacking and unsafe client-side storage.
- B07API authentication and object-level authorisation
Token handling, key rotation, object- and property-level authorisation on API resources, function-level access control.
- B08API inventory and exposure
Undocumented or deprecated endpoints, debug and internal APIs reachable from outside, excessive data exposure in responses.
- B09Rate limiting and abuse controls
Limits on authentication, messaging, export and other resource-intensive operations; protection against automated abuse.
- B10File upload and processing
Type validation, size limits, storage location, execution prevention and safe processing of uploaded content.
- B11Error handling and logging hygiene
Error responses do not leak internals; logs do not contain secrets or excessive personal data; failures are recorded.
- B12Business logic abuse
Workflow bypass, price or quantity manipulation, replay of one-time actions and race conditions in the key flows in scope.
- B13Account recovery flows
Password reset, email change and account recovery: token strength, expiry, single use and protection against takeover.
- B14Third-party integrations and callbacks
Webhook signature verification, OAuth flows, callback URL validation and least-privilege scopes for integrated services.
Code and supply chain
The source code, its dependencies and the pipeline that turns them into a running product — from secrets in history to build provenance.
- C01Dependencies and known CVEs
Software composition analysis of direct and transitive dependencies against published vulnerability records; unmaintained and end-of-life components.
- C02Secrets in code and history
Credentials, tokens, keys and certificates in the repository tree, commit history, build configuration and container layers.
- C03Static analysis (SAST)
Rule-based analysis of the source for injection, unsafe deserialisation, cryptographic misuse, insecure defaults and dangerous functions, with manual triage of findings.
- C04Software bill of materials
A machine-readable SBOM (CycloneDX or SPDX) exists, matches the deployed build and can be regenerated by the pipeline.
- C05CI/CD security
Pipeline permissions, secret handling in jobs, third-party actions and images, artefact signing and separation between build and deploy credentials.
- C06Dependency pinning and integrity
Lock files, version pinning, integrity hashes and controlled registries for packages, base images and build tools.
- C07Container image security
Base image currency, vulnerable packages, secrets in layers, running as root and unnecessary capabilities.
- C08Repository protection and code review
Protected default branches, mandatory review, signed commits or verified authorship, and restricted force-push.
- C09Build provenance and artefact integrity
Reproducible or attested builds, artefact signatures and verification before deployment.
Infrastructure
Cloud identity, network boundaries, secrets, patching, logging and recovery — the platform the product runs on.
- D01Cloud identity and least privilege
Root and administrative accounts, MFA enforcement, role scoping, long-lived keys and cross-account trust in the cloud accounts in scope.
- D02Public storage and data exposure
Object storage, snapshots, databases and file shares reachable without authentication or with over-permissive policies.
- D03Network segmentation and firewalling
Security groups, network ACLs, private subnets for data stores, bastion access and east-west restrictions.
- D04Secrets management
Central secret storage, rotation, access auditing and absence of secrets in configuration files, images or environment dumps.
- D05Patch and vulnerability management
Defined patch cadence, tracking of published vulnerabilities for the stack in use and evidence that Critical fixes are applied within the declared window.
- D06Logging, monitoring and alerting
Security-relevant events are logged centrally with retention, alerting on authentication anomalies and administrative actions, and protected from tampering.
- D07Backup and recovery
Backup coverage of production data, encryption of backups, off-site copies, restoration tests and recovery time objectives.
- D08Hardening baselines
Operating system and service configuration against a documented baseline, unnecessary services disabled, administrative access restricted.
Data and processes
How data is protected at rest and in transit, and whether the organisation has working processes for incidents, changes, vendors and deletion.
- E01Encryption at rest
Encryption of databases, object storage, backups and disks holding customer data; algorithms and key ownership.
- E02Encryption in transit
Encryption of internal service-to-service traffic, database connections and administrative channels, not only the public edge.
- E03Key management
Generation, storage, rotation, separation of duties and revocation for cryptographic keys and signing material.
- E04Access reviews and offboarding
Periodic review of who has access to production, timely removal on role change or departure, and administrative account inventory.
- E05Incident response
A written plan with roles, contacts, severity definitions, customer notification rules and evidence of at least one exercise or real incident review.
- E06Vulnerability handling process
Intake of external reports, triage, severity assignment, remediation deadlines and communication back to the reporter.
- E07Change management
Changes to production are reviewed, tested, approved and can be rolled back; emergency changes are recorded.
- E08Vendor and third-party risk
Inventory of sub-processors and critical vendors, their access, contractual security obligations and periodic review.
- E09Data retention and deletion
Defined retention periods, working deletion on customer request, deletion from backups within a declared window.
AI/Agent Security add-on Add-on
Additional checks for products that embed language models or agents acting on behalf of users. Available as an add-on to any level.
- F01Prompt injection resistance
Direct and indirect prompt injection through user input, retrieved documents and tool outputs; separation of instructions from data.
- F02Tool and action authorisation
Every action an agent can perform is bound to the permissions of the user it acts for, with confirmation for irreversible operations.
- F03Output handling and sandboxing
Model output is treated as untrusted: rendering, code execution, file and network access are constrained.
- F04Data leakage via model context
System prompts, other users' data and secrets cannot be extracted through the model; context is scoped per user.
- F05Retrieval and training data access controls
Retrieval sources respect the requesting user's permissions; training or fine-tuning data is governed and free of customer secrets.
- F06Model and prompt supply chain
Provenance of models, weights, prompts and plug-ins; version pinning and change review.
- F07Rate, cost and abuse controls
Limits on token usage, tool invocations and cost per user; detection of automated abuse.
- F08Logging and human oversight
Agent actions are logged and attributable; high-impact actions have a human checkpoint; users can see what was done on their behalf.
Severity model
Findings are rated with CVSS v4.0 as the baseline and adjusted for the business context of the product — data sensitivity, exposure and exploitability in the real deployment.
Known-vulnerability coverage
Vulnerability databases contain thousands of records about software weaknesses. We match identified components and versions to relevant records, then assess applicability within the agreed scope.
Database size is not a test count. The report identifies the components actually assessed, methods, results and limitations.
Relation to industry approaches
The methodology takes into account and uses elements of recognised industry approaches:
CyberSecurityV does not claim formal accreditation, partnership, certification by, or full conformance to these organisations or standards.