---
{
  "title": "Evaluating information sources",
  "summary": "Know where a claim came from and what it can actually support.",
  "topic": "soc",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    5
  ],
  "aliases": [],
  "sources": [
    {
      "title": "NIST: Technical Guide to Information Security Testing and Assessment",
      "url": "https://csrc.nist.gov/pubs/sp/800/115/final"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## Ask what the source can support

Evaluating a source means assessing its provenance, relevant expertise, evidence, independence, timeliness, and fit for the question. A polished website or confident tone is not a substitute for those qualities. Security analysis often depends on material that mixes direct observations, interpretation, and secondhand reporting, so separate them deliberately.

Primary material is especially useful when it directly addresses the claim: a provider's event documentation, an original advisory, a protocol specification, or an investigation's recorded artifact. Primary does not mean infallible; scope, assumptions, and later corrections still matter.

## Trace a repeated claim

A fictional analyst finds four articles claiming that a cloud service is affected by a new account attack. All four cite one original post. The articles may help explain the topic, but they do not represent four independent confirmations.

The analyst reads the original post, checks the publication and update dates, identifies the tested configuration, and looks for supporting evidence. A demonstrated weakness in one configuration should not automatically become a claim that every tenant is vulnerable.

They then consult the provider's current guidance for the relevant feature. If the guidance describes a mitigation, the analyst checks whether it applies to the environment being assessed rather than assuming a similarly named setting is equivalent.

## Separate reliability from relevance

A reputable source can publish accurate information that does not answer the current question. A report about a different platform may be useful background but weak evidence for a specific event in your environment. Conversely, an internal log may be directly relevant while still requiring checks on coverage, integrity, and field meaning.

Preserve uncertainty when a source lacks details. If a report names an actor without explaining the basis, treat that attribution differently from its directly documented technical observations. Do not convert someone else's confidence into your own without reviewing the support.

For time-sensitive claims, verify whether newer versions, corrections, or superseding guidance exist. Historical material can explain a mechanism while being unsuitable as current deployment advice.

## Keep a claim-to-evidence record

Write each important claim beside the source that supports it and a brief note on limitations. This makes review easier and prevents a general reference list from implying support for every sentence in a report.

For practice, compare an original advisory, a news summary, and a social-media comment about the same fictional issue. Identify which statements are firsthand, which are derived, and which remain unverified. Draft a conclusion that uses only the evidence available.

[[osint]] relies on this discipline when using public information. [[threat-intelligence]] applies it to decision-focused assessments, while [[incident-reporting]] uses it to keep facts and judgments distinct.