Ask any developer who just heard “we got a new licence, we need to become compliant” and I bet most of them won’t receive these words with joy: The Chief Risk Officer yells legalease from one side of the corridor (“you need to do access controls”), while the developers look at each other not knowing what code to write.
In this blog post series, we will illustrate what compliance is from a cloud developer’s perspective.
Compliance: The Customer’s Perspective
Let’s start by putting ourselves in the shoes of the customer. Imagine your relationship with your bank and how you would feel if:
- The bank went down for 4 hours and you are unable to make any purchase.
- Your friend, a developer at the bank, can check your transactions and change your account statement.
- The bank accidentally leaked your information to the public … and tried to lie about it.
- The bank tracks the location of your payments and you see ads in your browser from shops you visited.
The above items can be broadly grouped into business continuity, information security and privacy.
These issues are not just upsetting for an individual, they can lead to serious reputation losses and fines. In 2020, Swish, the Swedish instant mobile-to-mobile payment platform suffered outages and made it straight to the front page. In 2019, Equifax had to pay $575 million as part of a data breach settlement. Same year, Google was hit with a 50 million € fine for breach of the EU’s privacy regulation, GDPR.
Compliance: The Societal Perspective
Companies in certain sectors, such as BioTech, FinTech, MedTech, and those processing personal data, need public trust to operate. Such companies are allowed to handle sensitive data, create and destroy money, etc., in exchange for being compliant with certain regulations — in devtalk put, sticking to some rules set by regulators. For example, any bank operating in Sweden is regulated by Finansinspectionen (the Swedish Financial Authority) and has to comply with FFFS. Similarly, any company dealing with personal data is scrutinized by Datainspectionen (the Swedish Data Protection Authority) and needs to comply with GDPR. Such regulation is not only aspirational, but is actually checked as often as yearly by an external auditor. If the company is found to be non-compliant they might be forced to close shop and devs will have to brush up their LinkedIn profile.
Compliance: The Developer’s Perspective
Translating legalese into code involves several steps. First a Compliance Officer or Chief Risk Officer will identify what regulations apply to the company. Based on those regulations, they will draft policies to clarify how the company should operate — i.e., run its daily business — in the most efficient manner while complying with regulations. To ensure the policies do not have gaps, are non-overlapping and consistent, they will generally follow a reference information security standard, such as ISO/IEC 27001.
Compliance is not just IT, and, for better-or-worse, is a company-wide transformation. It involves all kinds of aspects, such as how employees are vetted — e.g., to reduce the risk of hiring a known convict of financial crimes — to how physical access to company offices is checked. Generally, the policies will need to be understood and interpreted by each head of department. For example, marketing will need to ensure that they only include trackers that respect EU citizen’s privacy. Sales will need to check that their Customer Relationship Management (CRM) Cloud solution does backups to ensure they don’t lose valuable customer information. Indeed, compliance not only affects your internal operations, but also how you choose suppliers.
In the next blog post, we will give an overview of compliance aspects that are the most relevant to the IT department.
