Risk Assessment for IT Projects: Template and Tips for Collaborating with Development Teams

How to convince developers with the right risk assessment so they consider your security requirements from the start

To ensure that your security and data compliance requirements are considered by development teams from the beginning of IT projects, you need a risk assessment that fits the language of IT. In this post, I share a template to be filled out by IT leads or project managers, serving as a basis for joint risk analysis.

I also give you practical tips on how to raise security awareness among the development team so that they consider the requirements of the information security officer and data protection officer from the kick‑off meeting onward. Many developers have a different understanding of security and often underestimate secure processes based on my experience.

Example of a Form for Risk Assessment of IT Projects

If you establish a process for new systems and enhancements, the IT department will get used to considering security requirements already at project kick‑off. Here you will find the core questions that one of my clients asks their development teams. You must adapt them to your business processes and legal requirements of your industry. After using it in the first two projects, a more security‑conscious culture was established among the IT lead and team leads on one of my customers.

The first part deals with security measures and types of data, because these aspects are easily understandable for developers. It gives you a clear overview of the goal, the sensitive data used, and the architecture of the IT project. This prepares you well for the risk assessment. To create a detailed risk assessment that not only satisfies the auditor but also protects systems and business processes, you should sit together with the project manager or IT team lead and guide them so that important threats are not overlooked.

Here you can download the template

Project Details

  • Identification Number:
  • Name:
  • Client/Requester:
  • Product Owner/Project Manager:

Architecture Description

  • Purpose of the System: brief description of the new or changed business process
  • Production Server Diagram (usually in DMZ) and connections to databases, email servers, and other internal and external services
  • Code and Function of Involved Systems and Microservices: examples are backend, frontend, load balancer, payment provider, and Apache servers

Security Measures

  • How are these systems secured/protected? Here, the usage of a firewall between servers, regular backups, and permissions for access to back‑office functions are explained. The different user groups can be listed.
  • Which network protocols are used? Here it is described where HTTPS, SSH, HTTP, and other protocols are used.
  • Which authentication methods are applied? Here the use of two‑factor authentication, local users and passwords, and users on the Active Directory is described. The use of SSH certificates can also be mentioned.
  • How is user management handled and who is responsible for it?
  • Which permission groups are set up and for what purpose?
  • Which data transfers and integrations (interfaces) are used and what security measures are implemented? Based on the architecture diagram, all connections between machines are listed, including browsers of customers and internal and external employees. For emails, it must be clarified whether personal information leaves the company’s data center, because emails can be read by third parties.
  • Are preventive security measures taken, e.g., backups and emergency measures? Here, backups (periodicity and contained data), access restrictions, and persons responsible for system recovery are described.
  • Who is responsible for regularly testing the system restoration from backup?
  • How often is testing of system restoration from backup performed?
  • Are changes (data, configuration, etc.) traceably documented? This concerns the use of repositories for configuration and auditing of changes to users, passwords, and permissions. But also the configuration values of databases.
  • Are controls/spot checks carried out, and if so, where, when, and by whom? Here it is described who checks that permissions match the employees’ tasks, that security measures have been implemented in the system, and that backups have been made.
  • Are there compensating control actions that enable early risk detection? Here, monitoring tools, the scope of logs, and their storage location are described.
  • Attachments such as network diagram and permission concept

Data Classification

  • What types of data are processed? Here, generally non‑personal data are described, while all fields with personal data are listed.

  • How critical are the data for other business processes of the company?

  • How critical is it from the customer’s perspective if data is unintentionally made public, stolen, altered, or deleted?

  • Is personal data stored in other systems?

  • Can the system’s function be fulfilled without processing personal data? By using distributed systems or designs for data‑lean systems, IT applications can be developed without sensitive data. How this works I describe later in this post.

  • The following types of data are collected and processed:

    • Personal data (customer/employee data)
    • Business‑sensitive information
    • Public data

System Access

From the corporate/internal networkFrom the Internet via VPNFrom the Internet without VPN
Internal employeesYesYesNo
External service providersYesYesNo
Business partnersNot possibleNoNo
CustomersNot possibleNot possibleYes

IT System Locations

  • DMZ: Protected network with access from LAN and Internet
  • Internal network
  • Externally hosted systems: Description of the data center or public cloud

Detailed Risk Assessment

Note: Usually this part is filled out only superficially by IT staff. Therefore, you must analyze the risks again together with the technical project manager and possibly request additional security measures.

_These risks must be coordinated with both the client department and the data protection officer and information security officer. And these measures must be considered in the project plan. Ideally, the development team provides you with evidence of the implementation. But usually, it is enough to make the team aware of the risks.

AreaPlanned Security MeasuresResidual RisksAssessment of Residual Risk
Datae.g., verification of queries by an employee. Logging of access to customer data. Blocking unusual queries of large amounts of financial or personal data.Unauthorized copies of customer data from backend systems by internal employees who already have access.Low
Systemse.g.: Backups and emergency exercises to secure systems. Redundant servers in production.Hardware failure causes an outageLow
Networke.g.: Firewall, Intrusion Prevention System, 24x7 monitoring of critical machines.Unauthorized access to backend systemsLow
Interfacese.g.: Encryption of all connections between servers. Use of captchas to block spammer bots.Reading of emails with customer inquiries by administrators.Low
UsersFor example: Access is only possible for internal and external employees who have gone through an approval process in which they justify the need for the rights. Auditing of tables with personal information and backup concepts.Copying, manipulation, and destruction of data not included in a backup.Low

Comments for Approval

The project has been reviewed in advance and, subject to the implementation of the required measures, is

  • approved
  • not approved

If technical changes occur after the risk assessment date, the risk assessment must be repeated.

Signatures

Date, SignatureDate, SignatureDate, Signature
Project ResponsibleData Protection OfficerInformation Security Officer
Hand and data connections

Master Data Governance and Data Connections

Talking about fines is pointless

It is better to focus on security‑relevant situations that are close to the everyday life of a product owner, an IT lead, or a team lead. In case of a data leak of customer, employee, supplier, or other personal data, the company faces fines of up to 4 % of the total worldwide annual turnover. However, this threat is too abstract and its probability of occurrence compared to an outage or unintentional data corruption in production is too low.

Developers are familiar with security techniques, but not with secure processes

When talking with the development team, you must build a linguistic bridge between IT security, which they are familiar with, and the security requirements of the organization. Encryption methods, techniques to avoid outages, authentication and authorization methods, audit tools, and network monitoring are known to experienced developers. However, risk analyses, estimation of losses due to security incidents, and processes to meet legal requirements are rarely learned. Also, handling secrets such as passwords and private keys does not happen in a secure way.

That is why in the kick‑off meeting or in the template you should focus on security measures, architecture, and sensitive data of the systems. It is good to mention how much stress the team has during an outage in production and how much effort the team has when a ransomware attack happens and all servers have to be rebuilt. These topics lead to greater awareness of security‑relevant issues and have a lasting and sustainable impact on the deployment and development process.

Later you can perform a detailed risk assessment of the project based on all this information.

Modern IT architectures can significantly reduce the cost of security measures

You must ask for data‑lean systems that contain no personal data, or consider moving critical features to another system so that IT architects consider other design concepts. Here it is important to convey to the IT architect that less sensitive data means less effort on the IT security side. This leads to lower costs for the company.

Since 2011, microservice architecture has offered a new design paradigm for applications, enabling the construction of distributed systems. If only some parts contain personal data or business‑critical functions, the IT team can focus on those parts and implement appropriate security measures and processes. This simplifies, for example, protection against data leaks, data corruption due to bugs, or avoidance of outages.

However, many IT architects still adhere to the concept of monoliths, where all functions and data reside in a single application. After a few months, the small parts become huge and data is copied from one microservice to another. In addition, common frameworks for system frontends do not yet support this new architecture. Nevertheless, we designed and successfully implemented a new system for trading oil‑based derivatives that requires no personal data. This led to low development costs. In another project, together with the legal department of a brick-and-mortar commerce company, we determined that the new system without personal data of the suppliers meets the requirements of the German Supply Chain Act.

Ask technical questions

One day we were sitting with a colleague at lunch and were thrilled when Michael, the information security officer of a German corporation, asked us why we were still using a frontend framework, jQuery. It has plugins that are rarely updated and in his opinion, could lead to security incidents. He was right, and at the same time he wanted to hear what I, as an architect, and my colleague, as a team lead, had to say. Because of Michael’s interest in our work, we were motivated to consider all his requirements with the same priority as those of other stakeholders.

If you have no technical experience, it is challenging to get into IT topics. Alternatively, you can work with an experienced team lead or developer who is not only security‑conscious but also has a good reputation as a helpful technician. This way you can enforce compliance and security requirements for new projects. You perform the risk analysis and calculate possible losses, while he helps you implement the measures. When I worked with Michael, he sent me to every kick‑off meeting so that I could act as a mediator between him and the IT team. This was good for all parties because all perspectives were integrated.

Your Experience

How do you proceed when you have to negotiate with the IT department about the requirements of new projects? Have you had similar experiences with architects, product owners, IT leads, and developers? If you have useful tips, feel free to leave a comment here.

essential