Lesson 3.1

The OSINT Cycle

Learning Objectives

  • Explain each phase of the intelligence cycle and how it applies to an OSINT investigation
  • Turn a vague request (“find out about Company X”) into specific, answerable intelligence requirements
  • Describe what happens to raw data in the processing and analysis phases, and why they are separate steps
  • Use time-boxing and stopping rules to avoid rabbit holes and scope drift
  • Walk through a complete investigation from question to delivered findings

Why OSINT Needs a Method

Beginners usually treat OSINT as “googling really hard.” That works for about twenty minutes. Then you have 40 browser tabs, a notes file full of half-related facts, and no clear answer to anything. Worse, you may have wandered into information you were never authorized to collect.

A method fixes three problems:

  1. Focus. You know what question you’re answering, so you know what to ignore.
  2. Repeatability. Someone else (a teammate, a client, a court) can follow your steps and get the same result.
  3. Defensibility. You can show that everything you collected was within scope and necessary.

The method most OSINT practitioners use is borrowed from the government intelligence cycle. The US Intelligence Community describes it with slightly different wording depending on the agency. The Office of the Director of National Intelligence (ODNI), for example, uses planning and direction, collection, processing and exploitation, analysis and production, dissemination, and feedback/evaluation. The names vary, but the flow is the same everywhere: decide what you need → get it → make it usable → make sense of it → deliver it → learn from it.

        ┌──────────────────────────┐
        │ 1. Planning & Direction  │◄──────────────┐
        └────────────┬─────────────┘               │
                     ▼                             │
        ┌──────────────────────────┐               │
        │ 2. Collection            │               │
        └────────────┬─────────────┘               │
                     ▼                             │
        ┌──────────────────────────┐    ┌──────────┴───────────┐
        │ 3. Processing            │    │ 6. Feedback          │
        └────────────┬─────────────┘    └──────────▲───────────┘
                     ▼                             │
        ┌──────────────────────────┐               │
        │ 4. Analysis              │               │
        └────────────┬─────────────┘               │
                     ▼                             │
        ┌──────────────────────────┐               │
        │ 5. Dissemination         │───────────────┘
        └──────────────────────────┘

In practice the cycle isn’t a strict one-way loop. Analysts often jump back from analysis to collection when they spot a gap. The diagram shows the intended flow, not a rule that you can never go backward.

Phase 1: Planning & Direction

This is the most skipped phase and the most important. Everything that goes wrong later usually traces back to a fuzzy start.

Start with the requester’s real need

Someone asks for OSINT because they have a decision to make. A pentest client wants to know how exposed they are to phishing. A SOC wants to know whether a suspicious domain is tied to a known threat actor. A journalist wants to verify whether a video was filmed where it claims. Ask: what decision will this information support?

Write intelligence requirements

An intelligence requirement is a specific question the investigation must answer. Good requirements are:

Quality Bad example Better example
Specific “Find info on Company X” “What email address format does Company X use?”
Answerable with open sources “What’s Company X’s internal network map?” “What internet-facing hosts and subdomains does Company X have?”
Tied to a decision “Who works there?” “Which IT and help desk staff are publicly identifiable, for the authorized phishing simulation?”
Bounded “Everything about the CEO” “What does the CEO publicly post that an attacker could use for a pretext?”

Large investigations often use a hierarchy: a few broad priority intelligence requirements (PIRs), each broken into smaller, specific questions that tell collectors exactly what to look for.

Set the boundaries

Before collecting anything, write down:
- Scope: which organizations, domains, people, and time periods are in bounds, and which are explicitly out (see Module 2 Legal & Ethical Boundaries)
- Allowed methods: passive only, or is some active recon authorized? (see 3.3-passive-vs-active-recon.md)
- Time budget: how many hours total, and per requirement
- Definition of done: what does a finished answer look like?
- OPSEC level: how careful do you need to be about being noticed? (see Module 8 OPSEC)

3.4-planning-an-investigation.md has ready-to-copy templates for all of this.

Phase 2: Collection

Collection is gathering raw data from sources that can answer your requirements. The key word is from sources that can answer your requirements. Before you open a browser, make a collection plan: for each requirement, list the source types most likely to answer it.

Requirement Likely sources
Email format Company website contact pages, press releases, document metadata, email-format lookup services
Internet-facing hosts Certificate Transparency logs, passive DNS, internet scan search engines
IT staff Professional networking sites, job postings, conference talks

The full source catalog lives in Module 5 OSINT Sources, and how to use specific tools is covered in Module 4 Collection Techniques.

Collection rules that save you later:
- Record provenance as you go: URL, date/time (UTC), and how you got there. You will not remember later. (More in Module 7 Verification & Reporting.)
- Capture before you analyze. Posts get deleted and pages change. Screenshot or archive first, think second.
- Collect only what the requirement needs (minimization). If you’re looking for an email format, you don’t need an employee’s family photos.
- Note what you didn’t find. “No results in X” is useful information and stops a teammate from repeating the search.

Phase 3: Processing

Raw collection is messy: duplicate results, screenshots, foreign-language posts, CSV exports from three different tools, and file metadata you haven’t extracted yet. Processing turns this pile into something you can analyze.

Common processing tasks:
- De-duplicating (the same subdomain from five tools is one subdomain)
- Normalizing formats (consistent date formats, lowercase domains, one spreadsheet instead of five)
- Extracting metadata from documents and images
- Translating foreign-language content, and noting that the translation is machine-generated if it is
- Structuring data into a table, a timeline, or a link graph (see 3.2-pivoting-and-link-analysis.md)
- Tagging each item with the requirement it relates to

Why separate processing from analysis? Because when you mix them, you tend to only process the data that fits the story you already have in mind. Processing everything consistently first makes it harder to cherry-pick.

Phase 4: Analysis

Analysis is where data becomes intelligence. You’re answering the requirement, not just restating what you found.

Analysis involves:
- Connecting data points (this username appears on these three sites, and all three share the same profile photo)
- Evaluating reliability of each source and corroborating claims with independent sources
- Identifying gaps: what you still don’t know, and whether it matters
- Considering alternative explanations: could these two accounts belong to different people?
- Stating a conclusion with a confidence level (confirmed / likely / possible / unverified)

A useful test: if your “analysis” could be replaced by pasting in the raw search results, it isn’t analysis yet. Compare:

  • Data: “j.smith@companyx.com appears in a 2021 breach.”
  • Intelligence: “Company X uses first.last@ addresses (confirmed, 6 independent examples). At least one IT staff address appears in a 2021 breach (confirmed via breach notification service), so password reuse is a realistic risk worth testing in the authorized phishing campaign (likely).”

Verification techniques, confidence language, and cognitive bias get a full treatment in Module 7 Verification & Reporting.

Phase 5: Dissemination

Intelligence nobody uses is wasted effort. Dissemination means delivering findings to the requester in a form they can act on:
- The right format: a formal report, a briefing, a ticket, a spreadsheet of IOCs
- The right audience level: executives want risk and decisions, technical teams want specifics
- The right handling: OSINT reports often contain personal data and are a roadmap for attackers, so limit distribution and protect the file
- Timeliness: a perfect report delivered after the decision was made is useless

Report structure is covered in Module 7.

Phase 6: Feedback

Feedback closes the loop. Ask the requester:
- Did this answer your question?
- What’s still missing?
- What new questions came up?

New questions become new requirements, and the cycle starts again. Feedback also improves your process: which sources were valuable, which were a waste of time, and where you lost hours.

The Cycle Inside the Cycle: Pivoting

Every time you find a new selector (an email, a username, a domain), you effectively run a mini-cycle: Is this selector in scope and relevant to a requirement? → collect on it → process → analyze → does it answer anything? This is pivoting, covered in depth in 3.2-pivoting-and-link-analysis.md. Pivoting is powerful, but it’s also the main way investigations drift out of scope, which is why the planning phase matters so much.

Time-Boxing and Avoiding Rabbit Holes

OSINT is addictive. Every result suggests three more searches. Without discipline, you’ll spend two hours on an interesting tangent that answers none of your requirements.

Practical controls:
- Time-box each requirement. Give it a fixed budget (e.g., 45 minutes). When time is up, stop, write down what you have, and decide consciously whether to spend more.
- Use a “parking lot.” When you spot something interesting but off-requirement, write it in a parking-lot list and move on. Review the list at the end, not in the moment.
- Check the requirement before every pivot. Ask: “Which requirement does this help answer?” If the answer is “none,” park it.
- Set stopping rules in advance. Examples: “Stop when the email format is confirmed by three independent examples.” “Stop at two pivots away from the company domain.”
- Watch for scope creep signals: you’re looking at family members, personal addresses, or accounts that have no link to the organization.
- Take breaks and re-read your requirements. Fatigue makes you chase anything that looks shiny.

Other Frameworks You May See

  • Berkeley Protocol on Digital Open Source Investigations: published by UC Berkeley’s Human Rights Center and the UN Human Rights Office (OHCHR) for investigations of human rights and international crimes. Its investigation cycle includes online inquiry, preliminary assessment, collection, preservation, verification, and investigative analysis. It puts extra emphasis on preservation and verification because findings may end up in court.
  • Pentest methodologies (e.g., PTES) put OSINT inside a larger “intelligence gathering” or reconnaissance phase that feeds threat modeling and exploitation.

The lesson is the same across all of them: plan first, collect deliberately, preserve and verify, analyze honestly, and deliver something useful.

Worked Example: Company X Phishing Exposure

Scenario: Your team has a signed contract to run an authorized phishing simulation for Company X (companyx.com). The scope is passive OSINT on the company and its employees’ professional presence only. The time budget is 6 hours.

1. Planning & Direction
- Decision supported: how to design a realistic phishing simulation and which training to recommend
- Requirements:
- R1: What email format does Company X use?
- R2: Which departments and roles are publicly identifiable?
- R3: What email platform and login portals does Company X use?
- R4: What current events at Company X could be used as a phishing pretext?
- Out of scope: personal social media, family members, home addresses
- Stopping rule for R1: three independent confirming examples

2. Collection
- R1: contact pages, press releases, document metadata from PDFs on companyx.com
- R2: professional networking profiles listing Company X, job postings
- R3: MX and TXT DNS records, certificate transparency logs for login-related subdomains
- R4: press releases and local news from the last 6 months
- Every item logged with URL, UTC time, and the query used

3. Processing
- 43 employee names de-duplicated to 31
- Subdomains from three sources merged into one list of 18
- Titles normalized into departments (IT, Finance, HR, Sales)

4. Analysis
- R1: first.last@companyx.com — confirmed (press contact, two PDF author fields, careers contact)
- R2: 31 employees identifiable; 5 in IT, 3 in Finance — confirmed from multiple profiles
- R3: MX records point to a major cloud email provider; a vpn. and sso. subdomain exist — confirmed
- R4: a recent office move and a new benefits provider were announced — confirmed; these make believable pretexts (“Update your benefits enrollment”)
- Parking lot: an employee’s personal blog mentions company network details (out of scope for this engagement; flag to the client rather than investigate)

5. Dissemination
- Short report to the client’s security lead: email format, role counts (no unnecessary personal detail), exposed login portals, suggested pretexts for the simulation, and recommendations to reduce exposure
- Report encrypted and shared only with the named contact

6. Feedback
- The client asks whether any exposed credentials exist for IT staff. This is a new requirement (R5) that needs a scope check with the client before collection.

Key Terms

  • Intelligence cycle: the repeating process of planning, collection, processing, analysis, dissemination, and feedback
  • Intelligence requirement: a specific question an investigation must answer
  • Priority intelligence requirement (PIR): a high-level requirement that is broken into smaller, specific questions
  • Collection plan: a mapping of each requirement to the sources most likely to answer it
  • Provenance: the record of where, when, and how a piece of information was obtained
  • Minimization: collecting only what the requirement needs
  • Time-boxing: giving a task a fixed time budget before reassessing
  • Parking lot: a list of interesting but off-requirement leads to review later
  • Selector: a piece of identifying data (email, username, domain, etc.) you can search on

Key Takeaways

  • OSINT is a method, not just searching: plan → collect → process → analyze → disseminate → feedback
  • Planning is the most skipped phase and the most important one
  • Turn vague requests into specific, answerable intelligence requirements
  • Record provenance while you collect; you won’t remember it later
  • Processing and analysis are separate so you don’t cherry-pick
  • Analysis answers the question and states a confidence level
  • Time-box requirements and use a parking lot to avoid rabbit holes
  • Feedback creates new requirements, and the cycle repeats

References

Free to use, copy, change and teach. Security For the Folks dedicates this course to the public domain under CC0 1.0 Universal: no permission or credit needed. Quoted material and the sources it links to belong to their own authors.