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.
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:
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.
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
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.
Ideally, you would need a few important components: