Adaptive US Blogs on Everything Around Business and Data Analysis

Integrating Cybersecurity into Requirements Engineering

Written by Manpreet Kaur | 6/18/25 8:12 AM

In today’s increasingly digital and threat-prone landscape, embedding cybersecurity into the software development lifecycle is no longer optional. It is a critical necessity. Business Analysts (BAs), as defined by the BABOK® Guide, are uniquely positioned to ensure that security considerations are an integral part of requirements engineering. This article explores how BAs can apply practices from the BABOK knowledge areas of Requirements Analysis and Design Definition and Requirements Life Cycle Management to identify, define, validate, and trace security requirements across the project lifecycle.

Why Cybersecurity Must Be Integrated Early

Cybersecurity breaches often occur due to inadequate attention to security requirements in the early stages of solution design. Waiting until development or testing to address security often leads to costly rework, vulnerabilities, and compliance issues. BAs can mitigate these risks by:

  • Identifying security requirements early during elicitation.
  • Embedding confidentiality, integrity, and availability (CIA) principles into functional and non-functional requirements.
  • Ensuring traceability of security requirements through design, development, and testing.

Role of the BA in Requirements Analysis and Design Definition

The Requirements Analysis and Design Definition knowledge area focuses on structuring and organising requirements, specifying and modelling requirements, verifying and validating information, and defining the solution approach. In the context of cybersecurity, this knowledge area becomes central to embedding security at the core of a system's design.

  1. Specifying and Modelling Security Requirements

As a BA, specifying clear, unambiguous, and actionable security requirements is fundamental. These requirements must be modelled in a way that is understandable for both business and technical stakeholders.

  • Functional Security Specifications:
    • Authentication: login process, multi-factor authentication (MFA).
    • Authorisation: role-based access control (RBAC), permission sets.
    • Session management: timeouts, session tracking, secure logout.
    • Logging and monitoring: define events that must be captured (e.g., failed logins, data access).

  • Non-Functional Security Specifications:
    • Encryption standards: TLS, AES, HTTPS.
    • Data retention and archival policies.
    • Performance impacts of security features (e.g., encryption overhead).
    • Disaster recovery and incident response timeframes.

  • Writing Security related User Stories

Example of user story:

As a verified external user, I want my Person Account to store my full name, email, and phone number,
So that I can be uniquely identified and contacted.

Acceptance Criteria:

  • Email must be unique
  • Phone must follow international number format
  • Identity verification must be set to “Verified” before activation of account

         BAs support:

  • Integrating misuse/abuse cases
  • Including security threats and controls within user story context

  • Data Model Mapping
  • System creates person account and user account. Define relationship between both the accounts.

Person Account (Account) - Represents the person as a customer/entity

   ↓ 1:1

                       Contact

   ↓ 1:1

       User Account - Enables login and user identity

       ↓ 1:1 indicates a one-to-one relationship between the entities

  • Develop data dictionary: A data dictionary is a structured document or tool that defines and describes the data elements used in a system or application. It acts as a reference guide for developers, business analysts, data architects, testers, and stakeholders to understand what data is collected, how it’s stored, and how it’s used.
    • Example of data dictionary

Field Name

Data Type

Mandatory/Optional

Object

Description

First Name

Text

Yes

Person Account

Given name

Middle Name

Text

No

Person Account

Optional

Last Name

Text

Yes

Person Account

Family name

Email

Email input

Yes

Person Account

Unique email address for log-in and communication

Phone Number

Text

Yes

Person Account

Contact phone number (used for MFA and correspondence)

Legal Address

Search and select

No

Person Account

Individual or business address

 

  • Modelling Techniques:
    • Process Models (BPMN): Highlight steps vulnerable to tampering or unauthorized access.
    • Use Cases and Misuse Cases: Include both normal behaviour and potential threat scenarios.
    • Data Flow Diagrams (DFD): Show how data moves and where it may be exposed.
    • Decision Tables: Outline security logic and exception handling (e.g., access denial conditions).
  1. Verifying and Validating Security Requirements

BAs ensure that each security requirement is:

  • Verifiable: It must be possible to test and confirm that the security feature works as expected.
  • Feasible: Within the technical and budgetary constraints.
  • Aligned: With organizational policies and legal obligations.

BAs conduct walkthroughs with cybersecurity teams and stakeholders to validate the feasibility, completeness, and clarity of security requirements. This also helps uncover hidden assumptions and potential vulnerabilities.

  1. Defining Solution Options with Security in Mind

BAs define solution options while balancing security with usability and performance. When recommending solutions, BAs:

  • Identify security implications of each solution option.
  • Recommend risk mitigation strategies (e.g., zero trust architecture).
  • Engage stakeholders in trade-off discussions (e.g., friction vs. security).

Role of the BA in Requirements Life Cycle Management

This BABOK knowledge area ensures requirements are managed, maintained, and traceable throughout the lifecycle.

  1. Traceability of Security Requirements:
    • Link security requirements to business needs, stakeholder concerns, and regulatory obligations.
    • Use traceability matrices to connect requirements to design components, test cases, and deployment.
  2. Requirement Prioritisation and Conflict Resolution:
    • Resolve trade-offs between security and usability (e.g., stricter password rules vs. user convenience).
    • Work with product owners and security leads to align backlog prioritisation.
  3. Change Management:
    • As new threats emerge, requirements must evolve. BAs help evaluate the impact of changes and update documentation accordingly.
    • Participate in change control boards or security governance meetings to advocate for requirement updates.

Embedding Security into the Agile Delivery Model

In agile environments, security must be woven into iterative planning and delivery. BAs support this by:

  • Including security acceptance criteria in user stories.
  • Facilitating backlog refinement sessions with a security lens.
  • Using Definition of Done (DoD) to ensure security checks are complete.
  • Encouraging DevSecOps practices for continuous security testing.

Common Pitfalls to Avoid

  • Assuming Security is Someone Else's Job: BAs must proactively champion security from the start.
  • Vague Requirements: Terms like "secure" or "confidential" must be translated into measurable and testable criteria.
  • Ignoring Non-Functional Needs: These often carry critical security implications and must be treated as equal to functional requirements.

Conclusion

Cybersecurity is not just a technical responsibility—it is a shared accountability where the BA plays a critical role. By applying BABOK-aligned practices to requirements engineering, Business Analysts help create secure, resilient, and compliant digital solutions. From elicitation to evaluation, integrating cybersecurity into every step ensures that vulnerabilities are addressed early, systems are designed with integrity, and end-users and stakeholders can trust the solutions delivered.