Assessment methodology

Evidence first. Confidence stated.

Aegisnode organizes externally observable signals into review-ready findings. This page describes what we collect, how we interpret it, and where the method stops.

Public methodologyVersion 1.0 / July 2026Applies toExternal vendor evidence reportsView fictional sample

The method is designed to support third-party risk review with reproducible external evidence. It does not certify a vendor, prove that a control operates effectively, or replace legal, procurement, privacy, compliance, penetration-testing, or internal security review.

01

Evidence collection

We collect signals available from the public internet for an authorized target and preserve enough context to explain each observation.

Scope

The supplied domain and discovered, attributable internet-facing assets form the assessment boundary. Discovery does not imply ownership with certainty; ambiguous assets are labeled or excluded.

Observation

Checks may include DNS records, certificate metadata, TLS negotiation, exposed services, HTTP behavior, security headers, public vulnerability references, and other externally observable configuration signals.

Normalization

Raw results are converted into consistent evidence records with target, timestamp, check type, observed value, and collection status.

Correlation

Related observations may be grouped into one finding. Association is based on technical evidence and is separated from facts directly observed.

Reproduction

Where practical, a finding includes the affected endpoint, observation time, and non-sensitive evidence needed for a reviewer or vendor to understand the result.

Collection boundary

Aegisnode is designed for non-destructive external observation. A report is a point-in-time view; internet-facing state can change immediately after collection.

02

Scoring

The score summarizes observed external posture. It is a prioritization aid, not a probability of breach or a certification result.

Each completed scan category produces a score from 0 to 100. The overall score is the weighted average of available category scores: TLS 20%, DNS 10%, email 15%, exposed ports 20%, HTTP headers 10%, detected technology 15%, and breach exposure 10%. If a category does not run, the completed weights are normalized before rounding to the nearest whole number.

90-100

Grade A

80-89

Grade B+

70-79

Grade B

60-69

Grade B-

50-59

Grade C+

40-49

Grade C

30-39

Grade C-

20-29

Grade D

0-19

Grade F

overall score = round(sum(category score * category weight) / sum(completed weights))

Category modules apply their own documented checks to produce category scores. The overall number should be read with the underlying findings and evidence; it is incomplete by itself.

03

Confidence

Confidence communicates how strongly the available evidence supports a finding. It is distinct from severity.

Confirmed

Direct evidence supports the condition, with clear target attribution and little interpretive ambiguity.

Observed

An external signal was observed, but scope, timing, attribution, or business context may still require review.

Inferred

The condition is a reasoned deduction from correlated observations and should be validated before a material decision.

Severity is not confidence

A potentially serious issue can have low confidence, while a minor configuration fact can have high confidence. Reports should show both so reviewers can prioritize validation separately from impact.

04

Human review boundaries

Human review, when explicitly included in the selected service, adds judgment and quality control; it does not convert external evidence into an audit or certification.

A reviewer may confirm target attribution, inspect evidence quality, consolidate duplicates, adjust severity or confidence, add context, and identify questions for the vendor. The report should identify whether human review occurred and who performed it.

Reviewers do not attest to controls they cannot observe, accept risk on the customer's behalf, provide legal advice, guarantee completeness, or claim that a vendor complies with a framework solely from an external scan. Risk acceptance and final vendor decisions remain with the customer.

05

Data retention

Retention should be limited to what is needed to deliver the selected service, preserve report history, support security, and meet contractual or legal obligations.

Exact retention depends on the active plan and customer agreement. The product should expose applicable retention terms at purchase or in the service agreement. Customers may contact Aegisnode to request information about deletion or retention applicable to their account.

Data categoryPurposeRetention approach
Target and account dataOperate the service and associate authorized scans.While the account or agreement requires it, then removed under the applicable deletion process.
Scan evidence and reportsShow findings, support history, and reproduce decisions.According to plan history limits and contractual terms; not represented here as a universal fixed period.
Security and audit eventsProtect the service, investigate misuse, and preserve accountability.For a limited operational or legal period appropriate to the event and agreement.
Sensitive data

External scanning should avoid collecting unnecessary personal data, credentials, private documents, or application content. Evidence presented to customers should be minimized and redacted where disclosure would create additional risk.

06

Limitations

External evidence is useful because it is independently observable. It is incomplete for the same reason.

  • A point-in-time scan may not represent later configuration or intermittent behavior.
  • Asset discovery can miss systems or incorrectly associate shared infrastructure without enough attribution evidence.
  • Absence of a finding does not prove absence of a weakness.
  • Public vulnerability references do not by themselves prove exploitability in a specific environment.
  • External checks cannot validate internal policies, staff behavior, data handling, access control operation, or contractual performance.
  • Network controls, rate limits, geography, or temporary outages can change what is observable.
  • Scores from different providers are not directly interchangeable because methods and scope differ.
  • No report guarantees that a vendor is secure, will remain secure, or will avoid an incident.
  • Aegisnode reports should not be presented as a compliance certification, audit opinion, penetration test, or legal conclusion.
  • Material decisions should consider vendor responses, documents, business context, and the customer's risk tolerance.

Inspect the output.

See how evidence, confidence, findings, and limitations appear together in a report.