What is a Technology Risk Review (TRR)?

Roman Buczyński – In ITDS since oct 2021. Currently working at Goldman Sachs SFL engineering team as a DevOps / SRE engineer. Providing constant service availability, setting up new deployments and supporting developers in daily tasks.

What is a Technology Risk Review?

When a company wants to ensure that all their applications / services are being secure and compliant, adhering to company established standards, it may implement a Tech Risk Review procedure. Tech risk review is a series of regulations connected with a series of questionnaires and review meetings that ask questions and guide the application to be compliant with established protocols.

These may include:

• security threats, like access restrictions, code vulnerabilities, data leaks,
• logging threats – application logs may contain restricted data / debug information like passwords / database contents or other information that should be controlled,
• ex(t=p)ensive resource usage,
• Infrastructure threats (opening ports, adding low security services).

Why don’t we like Tech Reviews?

Tech risk review may be a lengthy and seemingly needless procedure that requires a lot of cooperation with the TR team, documentation efforts, sometimes even redesigning some parts of the application. This requires effort and time, time that – especially in the developers eyes – might be considered wasted on something other than creating application code.

A list of questions that are hard to answer, a series of online or face to face meetings, spawning even more questions and so on.. You get the idea.

It is not uncommon that you need to prepare a design document which is more extensive than existing one, maybe throw in a diagram or two, maybe even gather some more backup in the form of your colleagues input to answer some questions.

What is it like?

It may be a challenge. I would suggest not to tackle this alone, most of the time the Tech Risk team is well prepared, armed with a lot of narrow-case questions, asking about details you might not have thought about before. Don’t be afraid of it, whatever you cannot answer straight away, or are uncertain of – take notes and ask them to wait for the answers when you get them. This is not something to be ashamed of, this is part of the process.

Read more about the human side of Fintech business: Combining software development with business analysis

What benefits does a Tech Risk Review have?

As mentioned before, the process might raise questions you did not think about and know answers to – which is a good thing, as it increases your knowledge of the application itself, the infrastructure, the application surroundings (other apps interactions), as well as gives you certainty that the service is compliant with current company standards and policies. It gives you the benefit of feeling that you have created a secure app, but also gives the TR team and the company itself assurance that it will fit into the company and not cause any harm, at least up to the point where such situations can be predicted.

How to start performing Tech Risk Reviews?

Ideally, you would need a few important components:

• Established company policies regarding microservice interactions / data security / communication policies / authorization and authentication, other as needed
• Trained staff to perform reviews, people who know their way around security and think out of the box to be able to ask correct questions, at least up until you prepare a documentation for reviews that fit the company.
• Software tools to do appropriate testing / pentesting / other – depending on the application.