Threat Intelligence Intake for SOC 2

What this control should accomplish

Threat information influences detections and decisions only when its source, relevance, confidence, permitted use, and operational owner are understood.

How to implement Threat Intelligence Intake

1. 1

   Start with the use case

   State whether each source supports blocking, detection, enrichment, investigation, customer communication, or analyst research and who owns that decision.

   You should end up with: Threat-intelligence use-case register

2. 2

   Evaluate and approve sources

   Assess relevance, reliability, update behavior, confidence meaning, data handling, and operational cost before connecting a source.

   You should end up with: Dated source assessment and approval

3. 3

   Define interpretation rules

   Document how confidence, age, context, and source reliability affect scoring, detection, blocking, or analyst review.

   You should end up with: Indicator interpretation and expiry rules

4. 4

   Test operational changes

   Validate mappings, false-positive impact, expiration, and rollback before a new or changed source can alter production decisions.

   You should end up with: Pre-production validation and release record

5. 5

   Review value and retire safely

   Measure whether the source supports useful cases, creates noise, remains current, and can be removed cleanly when no longer justified.

   You should end up with: Periodic source review with retain, tune, or retire decision

Evidence to keep, and what it should prove

Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.

Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.

Which records should you prepare for the audit?

How an auditor may test this control

Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.

• Confirm the intended control outcome

  Determine whether the control is designed to achieve this result: Threat information influences detections and decisions only when its source, relevance, confidence, permitted use, and operational owner are understood.

• Confirm ownership and operating cadence

  Compare the documented owner with the intended role (Security Operations / Engineering / Infrastructure), then compare dated records with the stated cadence: Continuous/ongoing; periodic review by risk.

• Establish the complete audit record set

  Reconcile active integrations in feed, SIEM, and detection systems to the source inventory, then compare integration-change history and the scheduled review calendar with approval and review records; account for rejected, disabled, retired, missed, and overdue sources.

• Prepare the as-of-date evidence for a Type 1 engagement

  The current source and feed inventory, approved interpretation rules, active integration configuration, and latest source review showing the intake process is designed and in use at the review date.

• Prepare period evidence for a Type 2 engagement

  Every threat-intelligence source addition, approval, material feed or interpretation change, scheduled source review, suspension, and retirement due or occurring during the review period, including rejected and overdue decisions.

• Inspect the policy / design artifacts

  Documents that define the control, its scope, ownership, and expected way of working.

  • Inspect feed inventories

    For each selected record, confirm it demonstrates The team can identify every active and retired feed, where it is consumed, who owns it, and how confidence and expiry are handled.

    • Feed or source
    • Status
    • Owner
    • Destination and use
    • Confidence handling
    • Review date

  • Inspect indicator confidence criteria

    For each selected record, confirm it demonstrates Confidence, source reliability, context, and age are interpreted consistently before an indicator changes detection, blocking, or analyst priority.

    • Confidence levels
    • Decision effect
    • Age or expiry rule
    • Context requirements
    • Approved owner
    • Effective version

• Inspect the approval / review evidence

  Records showing that an accountable person reviewed, approved, challenged, or accepted the work.

  • Inspect Threat-intelligence source approvals

    For each selected record, confirm it demonstrates Each active source was evaluated for a defined use, relevance, reliability, handling, ownership, and operational effect before connection.

    • Source name
    • Intended use
    • Assessment factors
    • Owner
    • Approver and date
    • Decision

  • Inspect source review records

    For each selected record, confirm it demonstrates Active sources are periodically assessed for usefulness, noise, currency, cost, and changes, ending in a retain, tune, suspend, or retire decision.

    • Source
    • Review period
    • Reviewer
    • Value and quality measures
    • Decision
    • Actions and due dates

• Trace the control from design to operation

  Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.

Common implementation and evidence gaps

• A feed is connected because it is popular, but no operating use or owner is defined.
• Indicators from different sources are treated as equally reliable and current.
• Expired indicators continue to block or escalate activity.
• Source changes reach production without testing their effect on detections or customers.
• The team cannot trace a detection decision back to the source version and context used.

Before you call this control ready

• Can every active source be tied to a current use case and accountable owner?
• Can an analyst explain how source confidence changes the resulting action?
• Are stale indicators expired or revalidated automatically?
• Can production-impacting source changes be traced to testing and approval?
• Has each source received a documented retain, tune, or retire decision?

Trust Services Criteria references

These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.

• CC2.1
• CC2.3
• CC7.2
• CC7.3

Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.

Related controls to review next