Sign up


June 15, 2018

Wouter ‐ Security Specialist

Security is important in every stage of your project. From the Discovery Phase to the deployment phase, and everything in between. This post will focus on the first project phase: Discovery.

At WORTH we use the word Discovery to describe range of activities that we do to discover the real pain points of the end-user. In short, the Discovery process lays the foundation for a project. Also, it ensures that everyone is aligned even before taking possible solutions into consideration. In this blog, we help you to recognise a partner that not only focuses on development, but also on design and security.


Click here to read the previous blog.

Organisations must change in order to ensure future growth and success. To do this, we have to maximise digital service potential to connect organisations with the outside world. While doing this, we must keep security in mind. Sometimes this makes you feel vulnerable, as though being connected to the outside world compromises security. However, this doesn't have to be the case.

What does it take to make your digital services accessible, without sacrificing security? In our previous post we identified that it takes structural attention on security throughout the software development life cycle.

Most projects at WORTH follow a four-step life cycle. First, we go into Discovery, followed by the design or, “Alpha” phase, then on to the Development phase, and finally the Deployment/Running phase.

blog2 security


The Discovery phase is focussed on the context of the (potential) project. First of all, what does the business and project risk profile look like? Secondly, what threats can be identified? Last but not least, what compliance requirements are applicable in the context of the project?

The output of the activities below can help determine the measures that are required in the following project stages:

  • Risks - Profile for business & project
  • Threats - Modelling what can go wrong
  • Regulations - Compliance discovery


Your team will need to understand your business and its business risk level context. Therefore, we suggest that you create a business risk profile.

The goal of the business risk profile is to define a risk level based on how exposed the organisation is to the world at large. We'll give you an example: an organisation such as an international bank will have a higher business risk profile than a local sports club. Exposure is an accumulation of your organisation’s business model, its potential threats and visibility. An international bank is more likely to be attacked than a local sports club, and the impact of a security incident is also much higher.

Initial Business Risk profile

grey security

The business risk profile provides an indication of the exposure; however, the project itself also has a risk classification.


Besides risks to the organisation as a whole, organisations can also have project specific risks. This means that an internet banking application or webshop has a higher risk level than a promotional website.

Initial Project Risk Profile

new 14.23.33

After defining your project risks, place your project on the exposure vs impact chart. Let's look at the sports club vs bank example again. A local sports club website has low exposure and a security incident is likely to be a low impact one. Of course, this depends on the type of project. Just imagine the difference in the security breach when we compare the online payment area of the local sports club, and the international banking system of a large world bank. In the event that confidentiality is compromised, or the integrity or availability of data, the impact will be much more severe for the bank.

Therefore, the business impact requires a deep understanding of what is important to the organisation running the project. For instance, internal and external factors such as financial damage, reputation damage, privacy violation or loss of data determine the level of the impact.

Changing risk levels

Risk levels are not static, but instead subject to continuous assessment. Business risk impact or likelihood are usually relatively stable, but they may change, due to events outside the organisation (press attention, regulation changes etc).

The project risks profile will no doubt change as we learn more about the project and uncover risks or threats. For instance, the threat modelling activity in the Discovery stage can inform the projects risk profile, but it will evolve beyond this.



Threat modelling aims to increase awareness of how the potential system operates, and in doing so, identify potential vulnerabilities.

In a traditional threat modelling session, your team will focus on identifying threat actors, assets, external dependencies and trust levels. However, in the Discovery stage, not all information will be in place. Do not let this prevent you from having your first threat modelling workshop.

The goal of the first threat model workshop is explicitly to identify threats and potential vulnerabilities related to the project by reviewing the project through interaction, collaboration and brainstorming. This in turn helps to build in security awareness from project onset.

The traditional threat modelling process:

  • Step 1: Decompose the Application
  • Step 2: Determine threats & rank
  • Step 3: Determine countermeasures and mitigation

In the Discovery stage, we limit the workshop to focus on Step 1 and 2. Countermeasures and mitigation will be part of the activities in project stages where we design the actual system. Hence, we will cover those in our next blog post.

The output of this threat model activity will be a whiteboard with high-level assets and threats identified, and a general increase in security awareness with the team. You will know which users you are potentially going to work with, what trust levels they will have, and if we will be processing blog posts or financial transactions.


Unrelated to how your application will take shape in future project stages, it will also need to comply with the law or the applicable regulations or standards. The earlier you are familiar with these regulatory requirements, the better. This can help shape future activities and will make sure you won’t run into unwanted problems in the deploy/audit phase of your project.

  • Step 1 - Inventory Often, your development partner will know what type of regulations you have to comply with. Think for instance of generic regulations like AVG, GDPR, and PCI DSS. But of course, your organisation will launch the service and will know best what specific regulations apply to your sector, business, project, etc. So again, a team effort is required here, in collaboration with your legal team / risk officer, product owner and delivery team.

  • Step 2 - Translate into security requirements Having a ticket named ‘comply with AVG’ in the backlog is not useful. Instead, we need a higher level of granularity to be manageable by the team. Any activities that are part of your development partners security baseline are covered by default and do not require specific focus. Thus, he trick is to identify any requirements beyond the baseline and which need attention.

The output of this compliance discovery is a list of specific requirements from applicable law and regulations, which also impacts the design of the service and may directly feed into the security requirements.

Disclaimer: in our experience, this helps to make security compliance actionable, but won’t guarantee compliance. To know if a system is compliant this will need an audit by a third-party entity.

Have you started your project with a security aware delivery partner? Then you will have had discussions about your organisations' and projects' risks, threats and the applicable regulations. Preferably, you have this before any system design or architecture takes shape.


In the next post we will cover the Design/Alpha stage. We use the output of the Discovery phase to design the actual solution in the Alpha phase. Of course, with security built in.

Stay up to date

Sign up

Sign up