Intelligence Requirements Development

---

Understanding Intelligence Requirements

Intelligence requirements are formal expressions of information needs that, when fulfilled, enable better decision-making about security risks, defenses, and responses.

Key Characteristics

Effective intelligence requirements share several important attributes:

• Question-Based: Framed as specific questions that need answering
• Decision-Oriented: Directly connected to choices stakeholders must make
• Actionable: Focused on information that enables concrete actions
• Specific: Clearly defined in scope and focus
• Measurable: Possible to determine when adequately answered
• Prioritized: Ranked according to organizational importance
• Achievable: Realistically answerable through available methods
• Relevant: Aligned with organizational risks and objectives
• Time-Bound: Associated with appropriate timeframes for response

The Difference Between Requirements and Collection

A common misconception is confusing intelligence requirements (what needs to be known) with collection tasks (how to gather information):

Intelligence Requirement	Collection Task
What threat actors are targeting our industry?	Monitor industry ISACs for threat reporting
How do threat actors typically exfiltrate data from our sector?	Analyze malware samples captured in our environment
What vulnerabilities are adversaries exploiting against our technology stack?	Subscribe to vulnerability feeds for our key technologies

Intelligence requirements should focus on the information need rather than how that information will be gathered. Collection planning follows once requirements are established.

---

The Requirements Hierarchy

Intelligence requirements typically follow a hierarchical structure that progressively refines broad information needs into specific questions:

Priority Intelligence Requirements (PIRs)

The highest level of requirements:

• Focused on strategic, high-impact information needs
• Directly connected to major organizational decisions
• Limited in number (typically 5-10 for most organizations)
• Approved by senior leadership
• Relatively stable over time

Example PIR: “What nation-state threat actors are targeting our industry and what are their primary objectives?”

Specific Intelligence Requirements (SIRs)

The middle tier of requirements:

• Derived from and supporting PIRs
• More narrowly focused on particular aspects of broader questions
• Moderate in number (typically 3-5 per PIR)
• Managed at the operational level
• Updated periodically as conditions change

Example SIR (supporting the PIR above): “What technical capabilities does APT29 employ when targeting healthcare organizations?”

Intelligence Collection Requirements (ICRs)

The most granular level of requirements:

• Highly specific questions supporting SIRs
• Directly translatable into collection activities
• Potentially numerous (multiple per SIR)
• Managed at the tactical level
• Frequently updated based on collection results

Example ICR (supporting the SIR above): “What command and control infrastructure has APT29 used in healthcare targeting over the past six months?”

This hierarchical approach ensures that granular intelligence activities maintain clear connections to the organization’s highest-priority information needs.

---

The Requirements Development Process

Creating effective intelligence requirements follows a structured process:

Phase 1: Initial Assessment

Establishing the foundation for requirements:

• Current Risk Landscape: Understanding the organization’s threat environment
• Business Context: Identifying critical assets, processes, and functions
• Existing Knowledge: Assessing what is already known vs. unknown
• Stakeholder Mapping: Identifying key intelligence consumers and their needs
• Resource Evaluation: Understanding available collection and analysis capabilities

Phase 2: Stakeholder Consultation

Engaging with intelligence consumers:

• Executive Interviews: Understanding strategic concerns and decisions
• Operational Discussions: Identifying tactical and operational needs
• Security Team Sessions: Gathering input from technical defenders
• Business Unit Meetings: Learning specialized concerns from different departments
• Documentation Review: Analyzing risk assessments, incident records, and strategies

Phase 3: Requirement Formulation

Creating draft requirements:

• Question Development: Crafting specific, answerable questions
• Hierarchical Organization: Structuring into PIRs, SIRs, and ICRs
• Gap Analysis: Identifying missing or overlapping requirements
• Feasibility Assessment: Evaluating which requirements can realistically be met
• Prioritization Framework: Developing criteria for requirement ranking

Phase 4: Validation and Approval

Refining and formalizing requirements:

• Stakeholder Review: Ensuring requirements address actual needs
• Technical Validation: Confirming requirements can be fulfilled
• Leadership Approval: Securing formal acceptance of PIRs
• Documentation: Creating formal requirement statements and references
• Communication: Distributing requirements to intelligence teams

Phase 5: Implementation and Review

Putting requirements into action:

• Collection Planning: Developing approaches to gather needed information
• Resource Allocation: Assigning analytical capabilities to requirements
• Tracking Systems: Establishing mechanisms to monitor requirement fulfillment
• Performance Indicators: Creating metrics to evaluate effectiveness
• Review Cycles: Scheduling regular reassessment of requirements

---

Stakeholder Engagement

Effective requirements development depends on meaningful engagement with various stakeholders across the organization.

Key Stakeholder Groups

Typical intelligence consumers include:

Executive Leadership

• Information Needs: Strategic threats, industry trends, risk landscape
• Decisions Supported: Security investment, risk acceptance, strategic direction
• Engagement Approach: Focused executive sessions, concise briefings
• Challenge: Translating technical details into business language
• Best Practice: Connect intelligence directly to business objectives

Security Leadership

• Information Needs: Threat actor capabilities, defensive priorities, program effectiveness
• Decisions Supported: Control implementation, resource allocation, security strategy
• Engagement Approach: Regular security briefings, program reviews
• Challenge: Balancing strategic and tactical intelligence needs
• Best Practice: Develop requirements that span multiple timeframes

Security Operations

• Information Needs: Attack indicators, threat hunting guidance, detection opportunities
• Decisions Supported: Alert prioritization, incident response, monitoring strategy
• Engagement Approach: Operational workflow integration, technical discussions
• Challenge: Ensuring requirements produce actionable intelligence
• Best Practice: Link requirements directly to defensive workflows

Risk Management

• Information Needs: Threat probabilities, impact assessments, control effectiveness
• Decisions Supported: Risk prioritization, control investment, compliance approaches
• Engagement Approach: Risk framework integration, assessment participation
• Challenge: Quantifying threat information for risk models
• Best Practice: Align intelligence terminology with risk frameworks

Business Units

• Information Needs: Industry-specific threats, partner risks, technology vulnerabilities
• Decisions Supported: Business process security, partner management, technology adoption
• Engagement Approach: Focused consultations, domain-specific briefings
• Challenge: Addressing varied concerns across different business functions
• Best Practice: Develop specialized requirements for critical business areas

Engagement Methodologies

Effective stakeholder engagement employs various techniques:

Requirements Workshops

• Structured sessions focused on identifying information needs
• Involves multiple stakeholders to identify overlapping requirements
• Uses facilitated exercises to elicit genuine information requirements
• Documents outputs in standardized formats
• Establishes priorities through collaborative exercises

Individual Consultations

• One-on-one discussions with key stakeholders
• Provides deeper understanding of specific decision-making needs
• Allows for candid discussion of information gaps
• Builds relationships between intelligence producers and consumers
• Creates advocates for the intelligence program

Security Incident Analysis

• Reviews past incidents to identify intelligence gaps
• Determines what information might have prevented or mitigated events
• Identifies recurring information needs during response activities
• Develops requirements based on actual security experience
• Creates clear connections between intelligence and security outcomes

Risk Assessment Integration

• Embeds intelligence requirements development in risk processes
• Identifies threat information needs based on risk modeling
• Aligns intelligence priorities with risk management priorities
• Ensures intelligence supports enterprise risk decision-making
• Creates shared language between intelligence and risk functions

---

Formulating Effective Requirements

The quality of intelligence requirements directly impacts the value of resulting intelligence. Well-crafted requirements share specific characteristics:

The SMART Framework

Effective requirements generally follow the SMART criteria:

• Specific: Precisely defined with clear parameters
• Measurable: Possible to determine when adequately answered
• Achievable: Realistically answerable through available methods
• Relevant: Directly connected to organizational risks and decisions
• Time-bound: Associated with appropriate timeframes

Question Construction

Well-formed intelligence requirements typically:

• Begin with interrogatives (what, who, how, when, where, why)
• Specify the scope and boundaries of inquiry
• Identify the subject matter with precision
• Avoid technical jargon unless necessary
• Include relevant temporal considerations
• Indicate the required level of detail

Examples of Effective vs. Ineffective Requirements

Ineffective Requirement	Effective Requirement	Improvement
“Provide information on ransomware”	“What ransomware variants are targeting our industry, and what initial access vectors are they using?”	More specific, bounded scope, actionable
“Tell us about APT29”	“What are APT29’s current targeting priorities, technical capabilities, and detection evasion techniques?”	Focused on specific aspects, supports defensive planning
“Monitor the dark web”	“What compromised credentials from our organization are being sold on dark web forums in the past 30 days?”	Collection method becomes specific requirement, time-bound
“Keep us updated on threats”	“What emerging threats have been observed targeting our technology stack that might affect our upcoming cloud migration?”	Connects to specific decision, more precisely defined

Priority Setting

Not all requirements deserve equal attention. Prioritization should consider:

• Impact: Consequences if the question remains unanswered
• Urgency: Timeframe in which the information is needed
• Decision Support: Significance of decisions the intelligence will inform
• Resource Requirements: Effort required to fulfill the requirement
• Feasibility: Likelihood of successfully answering the question

Most organizations benefit from a tiered priority system (e.g., Critical, High, Medium, Low) with clear definitions for each level.

---

Requirements Management

Once developed, intelligence requirements must be effectively managed throughout their lifecycle:

Documentation

Formal requirements documentation typically includes:

• Requirement Statement: The specific question to be answered
• Type Classification: PIR, SIR, or ICR designation
• Priority Level: Assigned importance tier
• Stakeholder Owner: Primary consumer of the resulting intelligence
• Business Alignment: Connection to organizational objectives or risks
• Review Schedule: Timeframe for requirement reassessment
• Success Criteria: How fulfillment will be measured
• Related Requirements: Connections to other questions
• Resource Implications: Collection and analysis needs

Centralized Repository

Requirements should be maintained in an accessible system:

• Central Database: Structured storage of requirements information
• Version Control: Tracking of requirement changes over time
• Status Tracking: Monitoring of fulfillment progress
• Assignment Management: Allocation to analysis teams
• Relationship Mapping: Connections between requirements
• Integration Capabilities: Links to collection and production systems
• Reporting Functions: Generation of requirement status updates
• Access Controls: Appropriate permissions for different users
• Notification Systems: Alerts for requirement changes or updates

Governance Process

Effective requirements management requires governance:

• Approval Authority: Clear decision rights for requirement acceptance
• Change Control: Process for modifying existing requirements
• Conflict Resolution: Mechanism for addressing competing needs
• Review Cadence: Regular reassessment schedule
• Performance Evaluation: Assessment of requirement fulfillment
• Resource Allocation: Process for assigning collection and analysis resources
• Stakeholder Communication: Regular updates on requirement status
• Quality Assurance: Validation of requirement formulation
• Sunset Procedures: Process for retiring obsolete requirements

---

Translating Requirements into Collection Plans

Intelligence requirements must be transformed into specific collection activities:

Collection Planning Process

The journey from requirement to collection includes:

1. Requirement Analysis: Understanding exactly what information is needed
2. Information Identification: Determining what specific data could answer the question
3. Source Evaluation: Assessing which sources might provide relevant information
4. Collection Method Selection: Choosing appropriate collection approaches
5. Resource Assignment: Allocating personnel and tools to collection tasks
6. Timeline Development: Establishing collection schedules and deadlines
7. Coordination Planning: Organizing activities across multiple collection functions
8. Success Criteria: Defining when sufficient information has been gathered
9. Risk Assessment: Evaluating potential collection challenges or limitations
10. Approval Process: Securing authorization for collection activities

Collection Requirements Matrix

A structured approach to collection planning often uses a matrix format:

Intelligence Requirement	Information Needed	Potential Sources	Collection Methods	Priority	Timeline	Assigned To
What vulnerabilities are being exploited against our industry?	Active exploit details, targeted vulnerabilities, attack vectors	Vendor advisories, ISACs, security research, incident reports	OSINT monitoring, information sharing groups, vendor intelligence	High	Continuous	Vulnerability Team
What are APT29’s current targeting priorities?	Target selection criteria, victim profiles, geographic focus	Government advisories, research publications, industry analysis	OSINT collection, partner sharing, commercial intelligence	Medium	Quarterly update	Threat Actor Team
How are ransomware operators bypassing our email security?	Phishing tactics, attachment types, evasion techniques	Internal incidents, security logs, malware samples	Internal telemetry, sandbox analysis, incident forensics	Critical	Monthly	Malware Analysis Team

Collection Planning Considerations

Effective collection planning addresses several key factors:

• Source Diversity: Ensuring multiple sources for critical information
• Resource Constraints: Working within available collection capabilities
• Information Reliability: Considering source credibility and accuracy
• Collection Risks: Addressing potential challenges or limitations
• Classification Issues: Managing sensitive or restricted information
• Technical Feasibility: Ensuring collection is technically possible
• Timeliness: Matching collection tempo to intelligence needs
• Legal and Ethical Bounds: Ensuring collection remains appropriate
• Integration Requirements: Connecting collection systems effectively
• Analysis Implications: Considering how collected data will be processed

---

Requirements Evaluation and Refinement

Intelligence requirements are not static documents; they require ongoing assessment and improvement:

Evaluation Criteria

Regular assessment should consider whether requirements:

• Remain Relevant: Still connected to organizational priorities
• Drive Value: Produce intelligence that informs decisions
• Are Answerable: Can be effectively fulfilled with available resources
• Have Appropriate Scope: Neither too broad nor too narrow
• Maintain Priority: Continue to deserve their assigned importance
• Avoid Duplication: Don’t overlap with other requirements
• Support Operations: Connect to actual security activities
• Are Well-Formulated: Clearly express information needs
• Are Properly Documented: Include all necessary context
• Satisfy Stakeholders: Meet the needs of intelligence consumers

Review Cycles

Requirements should be reviewed at different intervals:

• Quarterly Reviews: Systematic assessment of all active requirements
• Post-Incident Evaluations: Requirement adjustments after security events
• Annual Strategic Alignment: Major reassessment tied to planning cycles
• Stakeholder Feedback Sessions: Regular consumer satisfaction checks
• Collection Effectiveness Assessments: Evaluation of information availability
• Trigger-Based Reviews: Reassessment following significant changes
• Performance Metric Reviews: Analysis of requirement fulfillment metrics
• Product Utilization Assessment: Evaluation of intelligence consumption
• Emerging Threat Reviews: Requirement updates based on threat evolution
• Resource Allocation Adjustments: Requirement prioritization based on capacity

Refinement Process

The requirement refinement process typically involves:

1. Collecting Feedback: Gathering input from intelligence producers and consumers
2. Analyzing Performance: Assessing how well requirements have been fulfilled
3. Identifying Gaps: Determining where requirements are missing or inadequate
4. Evaluating Relevance: Confirming continued connection to business needs
5. Adjusting Formulation: Refining requirement wording for clarity and focus
6. Updating Priorities: Revising importance levels based on current conditions
7. Modifying Documentation: Updating formal requirement records
8. Communication Changes: Informing stakeholders of requirement adjustments
9. Updating Collection Plans: Revising collection activities based on new requirements
10. Establishing New Metrics: Creating updated performance indicators

---

Common Challenges and Solutions

Organizations frequently encounter obstacles when developing intelligence requirements:

Challenge: Vague or Overly Broad Requirements

When requirements lack specificity or have unrealistic scope:

• Solution: Apply the SMART framework rigorously to all requirements
• Solution: Break broad requirements into multiple specific questions
• Solution: Create requirement templates with examples of good formulation
• Solution: Establish peer review processes for draft requirements
• Solution: Train stakeholders on effective requirement articulation

Challenge: Disconnect from Business Needs

When requirements fail to align with organizational priorities:

• Solution: Establish formal links between requirements and business objectives
• Solution: Include business stakeholders in requirement development
• Solution: Map requirements to enterprise risk categories
• Solution: Create requirement justifications that explain business relevance
• Solution: Regularly validate requirements against strategic priorities

Challenge: Collection-Driven Requirements

When collection capabilities dictate requirements rather than information needs:

• Solution: Separate requirement development from collection planning
• Solution: Focus initial discussions on decisions and information gaps
• Solution: Challenge requirements that simply describe collection activities
• Solution: Train teams on the distinction between requirements and collection
• Solution: Evaluate requirements based on decision support, not collectability

Challenge: Requirement Proliferation

When too many requirements overwhelm available resources:

• Solution: Establish strict limits on the number of active PIRs
• Solution: Implement rigorous prioritization frameworks
• Solution: Require retirement of existing requirements when adding new ones
• Solution: Create tiered service levels based on requirement priority
• Solution: Implement regular requirement pruning exercises

Challenge: Static Requirements

When requirements don’t evolve with changing conditions:

• Solution: Establish mandatory review cycles for all requirements
• Solution: Implement trigger events that prompt requirement reassessment
• Solution: Create requirement expiration dates requiring renewal
• Solution: Develop metrics that identify stale or outdated requirements
• Solution: Include emerging threat forecasting in requirement development

---

Tools and Templates

Practical resources can facilitate effective requirements development:

Requirement Templates

Standardized formats for documenting requirements:

Priority Intelligence Requirement (PIR) Template

PIR ID: [Unique Identifier]
Requirement Statement: [Specific question to be answered]
Business Alignment: [Connection to organizational objectives]
Key Decisions Supported: [Decisions the intelligence will inform]
Stakeholder Owner: [Primary intelligence consumer]
Priority Classification: [Importance level]
Review Schedule: [Reassessment timeframe]
Supporting SIRs: [Related specific intelligence requirements]
Approval Authority: [Authorizing individual/group]
Approval Date: [Date of formal acceptance]

Specific Intelligence Requirement (SIR) Template

SIR ID: [Unique Identifier]
Parent PIR: [Associated priority requirement]
Requirement Statement: [Specific question to be answered]
Information Type: [Category of intelligence needed]
Consumer Group: [Primary users of the intelligence]
Priority Level: [Importance classification]
Timeframe: [Period the requirement addresses]
Success Indicators: [How fulfillment will be measured]
Supporting ICRs: [Related collection requirements]
Review Frequency: [Reassessment schedule]

Intelligence Collection Requirement (ICR) Template

ICR ID: [Unique Identifier]
Parent SIR: [Associated specific requirement]
Collection Target: [Precise information to be gathered]
Potential Sources: [Where information might be found]
Collection Methods: [How information will be gathered]
Priority Level: [Importance classification]
Collection Frequency: [How often collection occurs]
Technical Parameters: [Specific data points to collect]
Assigned Team: [Group responsible for collection]
Limitations/Constraints: [Known collection challenges]

Requirements Workshop Materials

Resources for facilitating requirement development sessions:

Stakeholder Questionnaire

• What security information do you currently lack?
• What decisions do you make that could benefit from better threat intelligence?
• How do you currently assess threats to your area of responsibility?
• What security incidents have occurred that better intelligence might have prevented?
• What threat information would most help you improve security in your domain?
• How do you currently consume intelligence products?
• What timeframes are most relevant for your intelligence needs?
• How do you measure the value of intelligence you receive?

Workshop Agenda Template

1. Introduction and objectives (15 minutes)
2. Current threat landscape overview (30 minutes)
3. Information gap analysis exercise (45 minutes)
4. Decision support mapping activity (45 minutes)
5. Draft requirement development (60 minutes)
6. Requirement prioritization (30 minutes)
7. Next steps and action items (15 minutes)

Prioritization Matrix

A structured tool for requirement ranking based on:

• Critical business function protection
• Potential impact if unanswered
• Time sensitivity of information
• Resource requirements for fulfillment
• Relationship to strategic objectives

---

Case Studies

Financial Services Example: Ransomware Intelligence Requirements

How a banking institution developed focused requirements:

• Situation: Rising ransomware threats to financial sector
• Approach: Conducted collaborative workshops with security and business teams
• Key PIR Developed: “What ransomware groups are specifically targeting our banking subsector, and what are their technical capabilities and initial access vectors?”
• Supporting SIRs Created:
  • “What are the primary initial access vectors used in recent financial sector ransomware attacks?”
  • “What data exfiltration techniques are ransomware groups using before encryption?”
  • “How are ransomware operators bypassing common security controls in financial environments?”
• Outcomes: Targeted intelligence collection led to specific defensive improvements, including enhanced email filtering and lateral movement detection, preventing two potential incidents.

Healthcare Example: Nation-State Targeting Requirements

How a healthcare system focused intelligence efforts:

• Situation: Concerns about nation-state interest in medical research
• Approach: Integrated intelligence requirements with risk management processes
• Key PIR Developed: “Which nation-state threat actors are targeting healthcare research institutions, what information are they seeking, and what attack methodologies do they employ?”
• Supporting SIRs Created:
  • “What technical indicators are associated with APT41 campaigns targeting medical research?”
  • “What social engineering themes are being used to target research personnel?”
  • “What data exfiltration methods are being used in nation-state healthcare targeting?”
• Outcomes: Requirements drove focused collection that identified specific targeting of research databases, enabling targeted hardening and monitoring.

Manufacturing Example: Supply Chain Intelligence Requirements

How a manufacturer developed supply chain security requirements:

• Situation: Growing concerns about supply chain compromise
• Approach: Cross-functional requirement development with procurement and IT
• Key PIR Developed: “What threat actors are targeting our industry’s supply chain, what are their objectives, and what compromise methodologies do they employ?”
• Supporting SIRs Created:
  • “Which of our critical suppliers have experienced security compromises in the past year?”
  • “What software supply chain attacks have occurred in manufacturing environments?”
  • “What vendor security assessments are being bypassed in recent supply chain compromises?”
• Outcomes: Intelligence requirements led to the identification of vulnerable supplier management systems, preventing potential compromise through third-party access.

---

Best Practices

Stakeholder-Centric Development

Putting intelligence consumers at the center:

• Begin with decisions, not collection capabilities
• Speak the language of business stakeholders
• Connect requirements directly to organizational objectives
• Validate draft requirements with those who will use the intelligence
• Establish feedback loops for continuous improvement

Requirement Quality Control

Ensuring well-formed requirements:

• Implement peer review processes for all requirements
• Create objective criteria for requirement evaluation
• Develop clear templates that guide proper formulation
• Establish governance procedures for requirement approval
• Train intelligence staff on effective requirement development

Integration with Security Processes

Connecting requirements to security operations:

• Align with risk management frameworks and processes
• Incorporate incident response lessons into requirements
• Link requirements to security control decisions
• Develop requirements based on security testing outcomes
• Connect requirements to security metrics and measurements

Sustainable Management

Creating maintainable requirement processes:

• Limit the number of active requirements based on capacity
• Implement regular review cycles for all requirements
• Establish clear retirement criteria for obsolete requirements
• Document requirement contexts to preserve institutional knowledge
• Create consistent taxonomies for requirement categorization

---

---