Possible deliverables
Possible deliverables
- External exposure map
- Prioritised findings report
- Hardening and hygiene plan
- Continuity scenario and incident first steps
02 / 06
Cyber · AI · Digital intelligence
Cyber exposure review
Read the visible surface, prioritise risk and strengthen protection without turning the assessment into a fear-driven catalogue.
The review connects public exposure, configuration, access, dependencies and continuity. It separates genuine urgency from foundational improvements and turns both into a practical order of action.
02
What the assignment should give you
- 01A clear view of exposed assets and access
- 02Priorities based on likely impact
- 03A risk-reduction plan aligned with available resources
How the assignment works
How the assignment works
A short, explicit process adapted to the sensitivity of the situation.
- 01
Scoping
We define the decision to support, relevant assets, constraints, authorised sources and required confidentiality.
- 02
Investigation
Collection and analysis follow the agreed scope. Facts, hypotheses and areas of uncertainty remain clearly separated.
- 03
Prioritisation
Each finding is assessed by reliability, likely impact and the effort required to act.
- 04
Delivery
You receive a readable synthesis, useful evidence and a roadmap that can be put into practice.
Common situations
Common situations
- Before launch or major change
- After an alert, visible leak or incident
- To frame a security roadmap
How can the assignment’s result be verified?
Use these examples to agree on a verifiable deliverable. Checks and thresholds follow the agreed scope; the examples below are not client results.
| What to check | Evidence to request | Decision it supports |
|---|---|---|
| Owned inventory | Domain or service, owner, provider, business function and observation date; out-of-scope items flagged. | Confirm what belongs to the organisation before proposing intervention. |
| Prioritised finding | Reproducible observation within authorised scope, journey impact and verification limits. | Address exposure affecting an important activity first. |
| Verified fix | Before/after state, check method, owner and date; explicit remaining risk. | Close a finding on evidence or retain an exception with an expiry date. |
| Recovery | Isolated restoration exercise report, observed duration and recovered-data checks. | Revise recovery objectives if the exercise misses the agreed target. |
Put the decision to the test
An inventory of 24 assets: what can actually be reviewed?
An external review identifies services with partly uncertain ownership. Before counting fixes, the team needs to know who can authorise an intervention.
Fictional teaching case. Figures explain the reasoning; they are neither client results nor thresholds required by a standard.
- observed assets
- 24
- owned and authorised assets
- 18
- ownership records to confirm
- 6
| Possible choice | Missing evidence or supporting reason |
|---|---|
| Claim 100% coverage | The six unattributed assets cannot be reported as verified. |
| Test all 24 assets indiscriminately | Being listed in an inventory does not authorise testing. |
| Review the 18 authorised assets and resolve unknowns | Separate the verified scope from the ownership questions still open. |
Read the decision and next check
The report covers 18 assets within the authorised scope. The other six remain unknowns with an assigned owner for clarification. Known exploitation is one prioritisation input alongside the actual version, exposure and business function.
The next check
Choose one remediated asset and verify its owner, actual exposure and remediation evidence. Repeat the check within the authorised window; a closed ticket without an observable result is insufficient.
What this case does not demonstrate
A service not observed during the review may remain reachable at another time or from another network location.
References and scope
- NIST — CSF 2.0 Organizational Profiles
Comparing current and target states helps identify gaps. This table illustrates a deliverable; it does not attest to CSF compliance.
- CISA — Known Exploited Vulnerabilities Catalog
The catalog identifies vulnerabilities known to be exploited. It informs prioritisation; absence from the list does not establish safety.
References checked on 15 October 2026.
Before the assignment
Frame a useful decision
A useful exposure baseline starts with assets genuinely under control and clear authorisation boundaries. The review connects external discovery, accounts, configuration and recovery; any intrusive testing needs separately agreed scope. The findings register connects each domain, service or identity to its owner, exposure evidence, potential impact and proposed remediation. Active tests stay within the authorised scope. A follow-up observation confirms the result or records the exception. This separates theoretical vulnerability, demonstrated exposure and accepted residual risk.
Information to gather
- Domains, services and owners to include
- Critical journeys and known incidents
- Observation window, exclusions and technical contacts
Decisions to prepare
- Which access or service should be reduced first?
- Which exceptions have an owner and expiry?
- Which restoration capability needs rehearsal?
Illustrative assignment
- Situation
- An acquisition brings domains and services with no shared inventory.
- Work
- Cross-check domains, owners, providers and critical journeys; confirm authorisation before active testing; rank each exposure by actual effect.
- Deliverable
- An owned asset register and reduction plan with closure evidence, dated exceptions and a recovery test.
Example acceptance criteria to agree during scoping
- Each priority asset has an owner and an authorisation boundary.
- Forbidden access is denied in authorised tests.
- Closure records correction evidence and remaining risk.
Related public methods
References: data, uses and limitations
Documentation reviewed on .
| Source and purpose | Verified data or benchmark | How to use it | Limitation to retain |
|---|---|---|---|
| FIRST · CVSS Describe technical vulnerability severity using an explicit method and vector. |
CVSS 4.0 scores run from 0.0 to 10.0. Base, Threat, Environmental and Supplemental metric groups serve different purposes. | Retain the score version, vector and date. Compare it with the installed version, access paths and business consequences before ordering remediation. | A high score is not evidence of exploitation; a low score does not mean a service has no risk. |
| FIRST · EPSS Estimate exploitation probability for a published CVE. |
The model looks ahead 30 days. Its score is a probability; its percentile ranks that score relative to other CVEs. | Record the data date and distinguish probability from percentile. Add asset exposure and confirmed exploitation evidence. | The model does not predict harm to your organisation. Low probability does not cancel a critical exposure. |
| CISA · Known Exploited Vulnerabilities Identify vulnerabilities listed by CISA as known to be exploited. |
The catalogue includes CVE, product, date added and required action. Its official repository also provides the data schema. | Check applicability to your products and retain the access date. Review the requested action and vendor advisory before confirming remediation. | Absence from the catalogue does not establish safety. Administrative deadlines in it are not automatically binding on every organisation. |
Email security: identity, alignment and transport
Email exposure: verify each sending path
A point-in-time DNS observation does not prove authentication of every message. A review must connect domains, platforms, signatures and results observed at reception.
- Inventory From domains, MAIL FROM identities and each platform’s d= values.
- Check alignment on authorised samples instead of drawing conclusions from one record.
- Distinguish DMARC policy, DNS availability and SMTP transport security.
Open the comparison and DMARC simulator →
References and status checked on · SPF · RFC 7208 DKIM · RFC 6376 DMARC · RFC 9989
Cyber incidents: recovery decisions and evidence
Connect exposure assessment to recovery conditions
An asset inventory becomes more useful when it also identifies critical services, dependencies and evidence required before return to service.
- Verify owners and authorisations for the reviewed assets.
- Connect a priority weakness to journey impact and restoration options.
- Treat recovery acceptance as a separate exercise with evidence and limits; exposure assessment alone does not validate it.
Explore NIST outcomes and the timeline →
References reviewed · NIST SP 800-61r3 · pp. 27–29, 34–35 · CSF 2.0 · Appendix A
security.txt and disclosure
Check that an external report reaches a team
Cyber exposure also includes the ability to receive a useful report. A security.txt file can make the contact discoverable, but its presence alone establishes neither channel availability nor case follow-through.
- Check /.well-known/security.txt, HTTPS, Contact fields and exactly one Expires.
- Preserve the exact host, redirects and policy link; do not extend scope to subdomains by default.
- Assign a publication owner and a report handler; distinguish receipt, assessment and remediation.
Read the security.txt reference and disclosure cases →
Sources checked on · IETF · RFC 9116 · §2.5, §3, §5
CVSS, EPSS, KEV and VEX
Preserve the facts justifying remediation order
An exposure review is more useful when each vulnerability connects to an instance and decision. Keep generic scores identifiable and dated, then relate them to the exposed service.
- Separate CVSS severity, EPSS probability, KEV listing and VEX applicability assertions.
- Establish product, version, access paths and owner before declaring local exposure.
- Record decision, interim control and verification evidence; an available patch is not a deployed fix.
Read the CVSS, EPSS, KEV and VEX reference →
Sources checked on · FIRST · CVSS 4.0 Specification · FIRST · EPSS Frequently Asked Questions · CISA · KEV official data schema · OpenVEX · Specification v0.2.0
OAuth/OIDC: audience and access
An OAuth/OIDC review must demonstrate denials too
Sample actual trust boundaries: provider, client, API, tenant and object. The ten fictional cases prepare acceptance review; they are not an executed audit.
- Keep the validation contract and its version alongside each observed result.
- Test ID/access token confusion, wrong audience and expiry.
- Verify signature, business authorisation and effective access removal separately.
See token recipients and the ten OAuth/OIDC cases →
Sources reviewed on · IETF · RFC 9700 · OAuth 2.0 Security BCP · IETF · RFC 9068 · JWT access token profile · OpenID Foundation · OpenID Connect Core 1.0 · IETF · RFC 8725 · JWT Best Current Practices · IETF · RFC 6749 · OAuth 2.0 framework
OSINT: evidence preservation
Preserve context before confusing a copy with proof
Incident response must connect retained traces to their source, scope and handling actions. A digest protects a content comparison; it does not reconstruct undocumented custody.
- Use distinct identifiers for the preserved reference and working copies.
- Record handovers, receipts and clock uncertainty.
- Preserve an observed discrepancy and its reference before investigating cause.
See copy lineage and the eight preservation cases →
Sources reviewed on · NIST · Digital Evidence Preservation · NIST IR 8387 · Full report · NIST · SP 800-86 · NIST SP 800-86 · Full report · NIST · FIPS 180-4 · Secure Hash Standard
SSRF: URLs and connections
A retry does not change destination policy
Resilience for a URL importer must preserve egress controls. A fallback address, proxy or redirect introduces another step to verify, even when the original string passed the application contract.
- Use the same parser and fields for validation and the HTTP client.
- Bind validated addresses to actual connections while preserving TLS and the original hostname.
- Test refusals and limits in an authorized lab without probing third-party services.
Read the 12 cases and connection controls →
Sources reviewed on · OWASP · SSRF Prevention Cheat Sheet · WHATWG · URL Living Standard · AWS EC2 · Instance metadata options · IETF · RFC 3849
Timelines: UTC and time zones
Reconcile logs without inventing their order
A later-received record can describe earlier activity. Clock changes and collection retries add ambiguity; sorting local strings does not produce a reliable incident timeline.
- Reconcile UTC instants while retaining received representations.
- Test repeated time, missing time and inconsistent offsets.
- Isolate conflicting identifiers and preserve every dated analysis snapshot.
Read the 12 cases and three dated snapshots →
Sources reviewed on · IETF · RFC 3339 · Python · PEP 495 · Python 3.12 · zoneinfo · IANA · Time Zone Database 2026e · IANA · 2026e Europe rules · OpenTelemetry · Logs Data Model
Files: quarantine and withdrawal
Include late tasks in file acceptance tests
Acceptance tests should trigger withdrawal or replacement while analysis is running. Expected behavior concerns final state and actual access, beyond the task’s own success status.
- Test failure, incomplete checks and retry.
- Change version or policy during a task and verify rejection.
- Withdraw access before a derivative returns, then replay permitted and forbidden reads.
View the three journeys and late task results →
Sources reviewed on · OWASP · File Upload Cheat Sheet · OWASP · Authorization Cheat Sheet · WHATWG · HTML input accept · PostgreSQL 18 · Transaction isolation
Explore the CISA KEV catalogue
Connect an exposure to an official entry
Start with a CVE or product in the dated catalogue, then check the vendor advisory, deployed version and access path. KEV adds a known-exploitation signal; it does not replace analysis of your environment.
- Keep the entry and catalogue version.
- Document the product/version match and remaining uncertainty.
- Separate remediation, mitigation and investigation.
Explore the catalogue and method →
CISA KEV · 2026.10.21 · Documentary review : 2026-10-22
Explore NIST CSF 2.0 outcomes
Connect exposure findings to expected outcomes
An inventory or vulnerability list describes part of the situation. CSF 2.0 also supports discussion of responsibility, protection, detection and recovery.
- ID.AM: reconcile observed assets, data, services and owners.
- ID.RA: describe a risk scenario and business consequences.
- PR.PS: examine maintenance and actual platform state.
- Document evidence and scope; do not turn a finding count into a compliance score.
Explore outcomes and evidence to examine →
NIST CSWP 29 · CSF 2.0 · 2024-02-26 · 2026-10-22
TLS certificates and open-source intelligence
CT: a discovery lead requiring qualification
Public logs help examine certificates associated with a scope. A CT result is documentary evidence, not a finding of an exploitable vulnerability.
- Match each name to an authorised inventory.
- Do not count duplicates across logs as separate assets.
- Separate issuance, deployment, expiry and observed exposure.
Read the CT dossier and dated log list →
Google Chrome · Certificate Transparency for Site Operators · Domain Privacy · consulted 2026-10-23
Extensions: permissions and access
Include the browser in exposure scope
A hardened site can still be visited from a profile with highly authorised extensions. Keep the boundary between site security, browser capabilities and managed-endpoint choices visible.
- Inventory the test profile’s extensions with version and accountable owner.
- Explain each required host and check optional permissions actually granted.
- Test restriction and removal; static manifest reading cannot replace code and traffic observation.
Read the permission directory and manifest examples →
Microsoft Learn · Manage Microsoft Edge extensions using group policies · Enterprise policy documentation consulted 2026-10-23
Media: sanitization and evidence
A recovery copy also has a retirement stage
A restoration test establishes a recovery path for a given scope. It does not show that retired media, key copies or out-of-scope data have been sanitized. Plan retirement without undermining validated retention needs.
- Connect backup copies, media and keys to owners and scope.
- Separate restoration success, retention expiry and sanitization evidence.
- Where CE is considered, examine key copies or escrow outside the medium.
Read the methods, evidence points and annotated situations →
NIST · SP 800-88 Rev. 2 · Guidelines for Media Sanitization · Final · 2025-09-26 · consulted 2026-10-23
Syslog codes and collection evidence
A syslog code cannot qualify an incident alone
During triage, preserve the raw value, source and normalisation rule. Informational severity may document a sign-in or action relevant to an investigation; Emergency remains a sender declaration.
- Connect the message to a known asset and exposure context.
- Compare the raw event with the value displayed in the SIEM.
- Connect alerts to decisions and state collection gaps.
Read syslog codes and try the PRI calculation →
IANA · syslog Parameters · Registry updated 2016-04-26 · consulted 2026-10-23
ASD ACSC and partners · Best practices for event logging and threat detection · Published and reviewed 2024-08-22 · consulted 2026-10-23
API errors: types, statuses and evidence
An error response establishes neither failure nor safe replay
After interruption or an inconsistent response, a call may have produced an effect. Problem Details improves description; it does not prove no processing occurred or provide a universal retry policy.
- Preserve HTTP status, received body and permitted operation identifier in controlled traces.
- Check business state and idempotency rules before repeating an action.
- Test public messages without exposing secrets, internal paths or account details.
Explore problem types and eight fictional responses →
IETF · M. Nottingham, E. Wilde, S. Dalal · RFC 9457 · July 2023 · obsoletes RFC 7807 · §3.1, §3.2, §4.2, §5
CSP: directives, fallback and journeys
Describe third-party resources before relaxing CSP
Adding a script may also load images, open connections or embed a frame. Inventory requirements per journey and inspect every received policy rather than merge all origins into a global permission.
- Distinguish loading an iframe from permission to embed your own page.
- Read effective fallback for scripts, workers and connections.
- Test the documented third-party need without adding a wildcard to hide an error.
Read CSP fallback orders and explore eight scenarios →
W3C · Content Security Policy Level 3 · Mike West, Antonio Sartori · Working Draft · 2026-09-16 · work in progress · §2.2.1, §3, §6.8.3–6.8.4, §8.1
GraphQL: errors, lists and partial data
Audit GraphQL at object and field level
Start with the caller’s rights on each requested datum; an error-free response is not sufficient evidence.
- Compare absent data, partial data and data: null.
- Keep the original path even when a parent becomes null.
- Test permissions, quotas and interface states separately.
Explore GraphQL responses and nullability →
GraphQL Specification · September 2025 · Published edition · September 2025
Core Web Vitals: thresholds and field data
Web review: performance evidence must be comparable
A Lighthouse score, CrUX p75 and keyboard journey provide different evidence to combine in acceptance checks.
- Compare the same device, scope and documented periods.
- Do not turn missing data into zero.
- Verify functions and accessibility after the fix.
Read the thresholds and try the p75 reader →
Google · About PageSpeed Insights · Living documentation · consulted 2026-10-23
Product identity: GTIN and variants
Catalog review: separate identity evidence from check digits
A positive arithmetic result describes neither brand nor authenticity; verify business sources.
- Preserve zeros and raw values useful for acceptance checks.
- Test the URL preselecting each variant.
- Compare identity, price and availability on the page and in the cart.
Explore identifiers and check a GTIN digit →
GS1 · 2D Barcodes at Retail POS Implementation Guideline · Release 1.1.0 · ratified December 2025 · §4.3 / Table 4-2
Google Search Central · Product variant structured data · Updated 2026-09-08 · consulted 2026-10-23
Citation chains and social monitoring
Social monitoring: from reposts to a decision
Visible volume alone does not explain reputation risk. Document shared sources, collection scope and actually observed effects before recommending a response.
- Separate messages, documents and people: the units are not interchangeable.
- Prepare an Actor, Behaviour, Content, Degree, Effect briefing with explicit unknowns.
- Set a review deadline, including when the decision is to monitor without responding.
Read the method and explore citation chains →
Government Communications · RESIST 3 · RESIST 3 · 2025 · consulted 2026-10-23
Government Communications · RESIST 3 quick reference · RESIST 3 · 2025 · consulted 2026-10-23
A/B allocation: data and SRM
A/B tests: check allocation before deciding
An unexplained discrepancy may arise from assignment, the executed journey, logs or analysis filters. SRM supports investigation; it does not measure product improvement.
- Check intended allocation and unit stability before comparing conversions.
- Do not interpret absence of a signal as proof of overall validity.
- Document the quality check, measured effect and deployment decision separately.
Explore the allocation check and its limitations →
Microsoft Research · Diagnosing Sample Ratio Mismatch · Published 2020-09-14 · consulted 2026-10-23
NIST/SEMATECH · Binomial distribution · e-Handbook §1.3.6.6.18 · consulted 2026-10-23
API deprecation and retirement
Announced retirement and continuity to verify
A Sunset field signals intent; it establishes neither actual shutdown nor guaranteed continuity until then. Prepare dependencies, data and access to move.
- Identify the announcement’s exact scope and owner.
- Keep dates and updates with receipt evidence.
- Test exit, in-flight operations and removal of obsolete access.
Compare deprecation and retirement announcements →
IETF · RFC 9745 · Deprecation · Standards Track · March 2025 · §2–5 · consulted 2026-10-23
IETF · RFC 8594 · Sunset · Informational · May 2019 · §3–5, §8 · consulted 2026-10-23
RAG relevance and ranking
Relevance and permission need separate checks
A relevant document may be forbidden to the requester. Build the evaluation corpus within accessible scope and test denials independently of ranking scores.
- Keep permissions and document versions with the test set.
- Check revocation, deletion and citation paths before measuring relevance.
- Do not use an nDCG improvement as evidence that permissions are respected.
Explore ranking measures and relevance judgments →
Stanford CS276 · Retrieval evaluation · 2019 course archive · PDF pp. 3, 5–6 · consulted 2026-10-23
NIST TREC · Reciprocal rank definition · Repository snapshot 35cf096ba6d5ae08ca4803c056b31ed61a56a6d4 · consulted 2026-10-23
FAQ
Frequently asked questions
Practical answers to help frame the need before an initial conversation.
Does a cyber exposure review involve intrusive testing?
Not by default. The review starts with external exposure, visible configuration and material supplied with authorisation. Any active testing requires a separate, explicit scope and approval.
What do we receive after the review?
The deliverable ranks findings by impact and urgency, explains corrective measures, identifies possible owners and proposes a realistic order of action.
How can a cyber finding be checked before closure?
Replay the authorised check on affected assets and record the date, configuration and result after remediation. Distinguish confirmed correction, accepted exception and a check still impossible; assign outstanding issues. Closing one finding does not establish that the system has no other vulnerabilities.
Digital ecosystem
Extend the analysis with specialist resources.
Française du Numérique
Web creation, SEO and content
francaise-du-numerique.fr
ENExplore
French Digital Society
Digital professions and expertise
french-digital-society.com
ENExplore
Internet Intelligence Service
OSINT, monitoring and due diligence
internet-intelligence-service.com
ENExplore
CFSN
Digital support for small businesses
cfsn.fr
French editionExplore
World Affiliate Guide
Affiliate and performance marketing
world-affiliate-guide.com
ENExplore
World Social Networks
Social networks, usage and privacy
world-social-networks.com
ENExplore
World Web Certified
Curated web directory and guides
worldwebcertified.com
ENExplore