The Influence of Cybersecurity Practices on Project Management in Software Engineering

The Influence of Cybersecurity Practices on Project Management in Software Engineering. In this 2026 study for the International Journal Of Electrical Engineering And Intelligent Computing, Shaymaa A. Chyad, Fırdews A. Alsalman and Esra Zuhair Majeed examine how building security into project work relates to how delivery is planned and managed. They examine relationships with timelines, budgets, team collaboration and risk management. By the end, you should understand what the survey measured, what relationships appeared, and why its perception-based design cannot show that any individual security practice caused a better project outcome.

SDLC, which stands for software development lifecycle, covers the path from requirements and design through implementation, deployment and maintenance. The researchers organize security work by stage. Threat modeling identifies risks during requirements and design. Secure coding, encryption and authentication address implementation, while penetration testing checks the result and continuous monitoring extends oversight into operation. They connect this work to delivery concerns such as time, cost, collaboration and risk. Earlier research often offered frameworks without checking them against collected evidence, while quantitative evidence connecting security integration with project management remained limited.

Rather than asking only whether a control blocks an attack, the researchers ask how security work relates to project management. Their goal is empirical: to check the idea against collected responses instead of relying only on conceptual frameworks. There is an important distinction, though. The named security practices informed the questionnaire, but the researchers did not turn each practice into a separate statistical predictor. The analysis instead examines how respondents’ ratings of timeline, budget, collaboration and risk preparedness relate to one another.

The researchers surveyed 128 software professionals recruited specifically for relevant experience. Respondents included developers, IT and cybersecurity staff, and project managers from several sectors. The questionnaire used closed-ended rating items about delivery and risk, plus predefined multiple-choice questions about integration challenges and possible improvements. Field experts reviewed the questionnaire for clarity and reliability. The analysis included descriptive summaries, Pearson correlations and multiple linear regression. For the organizational questions, respondents could choose several answers, and the researchers counted each selected category.

Respondents commonly perceived that integrating security increased project costs, although opinions varied. Several also thought security could delay timelines, but they did not generally view those delays as a large disruption across all projects. Risk-management preparedness was significantly associated with ratings for timeline management, budget influence and collaboration; stronger preparedness accompanied more favorable perceptions across those areas. The analysis also identified training gaps, budget constraints, unclear responsibilities, late security involvement and weak cross-team collaboration. These are associations and perceptions, not evidence that a named control independently improved delivery or security.

The questionnaire connected threat modeling to early risk identification, secure coding and access protections to implementation, penetration testing to validation, and monitoring to deployed systems. But those practices served as the conceptual basis for survey items, not independently measured predictors. That means the statistical evidence cannot isolate the effect of penetration testing, threat modeling or another specific practice. For the multiple-response questions, participants could select several researcher-defined options. Each response category was treated separately; the process did not use qualitative coding or inter-coder reliability. The researchers combined the multiple-response findings with the quantitative findings to interpret the results.

The interpretation is constrained by self-reported data from 128 people, and the researchers warn that the results may not generalize. Participants were deliberately selected for relevant experience rather than sampled randomly, which may introduce selection bias. Participating organizations also had prior experience implementing cybersecurity, potentially narrowing how well the findings apply elsewhere, and nonresponse bias remains possible. More fundamentally, the study captured people’s views rather than operational measurements of vulnerabilities, incidents or delivery performance. Because the security practices were not separate predictor scales, the analysis cannot attribute an outcome to any individual control or demonstrate causation.

Security and delivery leads can treat these findings as prompts for project design, not proof of return on investment. The recommendations cluster around early ownership, sustained resourcing and shared execution. That means involving security during planning and design, defining responsibilities clearly, setting aside an explicit cybersecurity budget, providing ongoing role-specific training and using cross-functional teams. An operational interpretation would be to schedule threat modeling early, assign security ownership, and reserve time for validation and monitoring before delivery plans harden. That interpretation is not an experimentally tested recipe. Teams should evaluate it against actual delivery and security outcomes throughout their own development lifecycle, an area the researchers identify for longer-term study.

Chyad, Alsalman and Majeed contribute survey evidence linking security integration with respondents’ perceptions of project delivery and risk preparedness. They also identify organizational barriers to that integration. For application security leads and software project managers, the practical takeaway is to discuss security involvement early, provide appropriate resources and make ownership clear. Do not infer that a particular control caused a project or security improvement, or assume that the same relationships will hold in other organizations.