George Totev joined Atlassian after stints with a number of prestigious technology and financial institutions, including IBM, the World Bank, Sybase, Goldman Sachs, and Visa. These organizations all shared a vital priority: reliably safeguarding the information customers entrusted them with. Meet George and find out how he took on those challenges, and the lessons and insights he brings to Atlassian.
You have lots of experience working for financial institutions, which are not necessarily known for embracing disruption. Now you’re at a fast-paced software company. How do you approach regulatory compliance in an industry that depends on innovation and speed to market?
George: Risk management is the practice of achieving balance — the balance between hazard and opportunity risks. Unfortunately, too often we focus on the hazard risks. Combined with another cognitive bias — being pretty bad at assessing probabilities — it leads to what we all know as “check-the-box” compliance.
Compliance, in general, is a tool to aid risk management. Its goal is to address the most common risks in the most common use cases. Therefore, when a particular framework is published, usually it is accompanied by a set of recommendations, or “best practices.” (I don’t really like this term, because in a lot of cases those are actually pretty average practices.)
However, as we all know, risk is very contextual. What works for one company may not be appropriate, or efficient, or effective, for another. So, with “check-the-box” compliance, we may end up with not only mediocre risk management, but also a false sense of having managed the risk. A pretty bad outcome, I would say.
Risk is very contextual. What works for one company may not be appropriate, or efficient, or effective, for another.
Sometimes the information security team, for example, will take the “big stick” approach to enforcing compliance, not realizing that they may be increasing exposure to risk because engineering will just go around you. And then you have a security team that doesn’t know what’s going on.
Let me be absolutely clear — I do not want in any way to diminish the value we receive from standards. In most cases, there is great value in following a particular framework, even if you don’t go all the way and certify. My point is that implementation of those standards should be done very carefully, with a lot of thought and consideration about the specifics of your particular case, weighing the pros and cons of every control.
That was exactly the approach I took when establishing the Risk & Compliance function at Atlassian. One of the main pillars of our philosophy is that we focus on risk management and use compliance as a tool. We will never do anything that does not make sense from a risk perspective — no “check-the-box compliance.”
One of the main pillars of our philosophy is that we focus on risk management and use compliance as a tool. We will never do anything that does not make sense from a risk perspective — no “check-the-box compliance.”
This fundamentally had an effect on how we structured the team, how we operate, and what tools we use. For example, the Risk & Compliance managers are embedded in the business units. That allows them to have an excellent perspective on that business unit. They are part of the team, and instead of dictating what controls we need to implement, they are seen as an advisor. The tools we use to manage risk and compliance (you guessed it — Jira and Confluence, of course) are highly integrated within business units operations.
That sounds very interesting. Do you have specific examples of how you implemented that philosophy?
George: Certainly. Let’s take one of the major challenges organizations face — how to manage change, especially low-level changes. The “traditional” way is to have a Change Approval Board, or CAB, that meets to review all change requests and approves what is appropriate. Usually, the CAB consists of mid- or upper-level management, and the requestor presents and they all discuss the change.
For companies that use Agile and continuous deployment, such a process will slow down deployment significantly and have a negative effect on innovation. Additionally, for large organizations, it may provide questionable risk reduction, because it would be really hard for the CAB to have a deep understanding of the specifics of the change.
When we were designing our change management process, we followed our philosophy and worked directly with the development teams. We explained what the criteria and objectives of the control, and built upon the existing peer review process, and we achieved a nice risk balance between speed and safety.
Atlassian is a relatively small company compared to the corporations you worked at before. Have you had to adjust your approach?
George: I don’t believe Atlassian is small — just look at our product portfolio. Our products are fairly well integrated, we have a common platform, and still they are quite independent. Atlassian, in a way, is like a conglomerate. We have to accommodate for different risk profiles, product intricacies, and use cases. That creates some complexity, which creates more uncertainty, so we make very determined efforts to reduce complexity as much as we can. We use the Atlassian Control Framework, and we try to reuse controls and processes wherever appropriate.
Complexity, in general, creates more uncertainty, so we take very determined efforts to reduce complexity as much as we can.”
Having such variety is not just a risk; it’s also an opportunity to learn from each other, especially as we acquire companies and these new teams bring in different approaches to solving problems. For example, one company we acquired, Opsgenie, had a very strong focus on resiliency — preventing incidents. So they had a lot of redundancy and a lot of processes within their own environment to minimize the likelihood of a disaster event. We were able to adopt some of them across the rest of the organization, and next year we’re going to have a whole program around resilience.
With so many varied regulations to comply with, how do you make sure Atlassian is compliant without bogging our teams down with red tape?
George: I mentioned the Atlassian Controls Framework — a sort of “theory of everything” that unifies all applicable compliance standards and controls into one universal framework. The idea is that you take a set of frameworks, such as SOC2, PCI, ISO, etc., and look at the categories of controls within each — like change management, business continuity, access control — and then you combine them to create your own unique set of controls.
The great advantage of this approach is that it creates huge efficiencies in both implementation and auditing, saving the company a ton of time, hassle, and money. And you get the added benefit of including controls you want to cover that are outside of any existing standards, so the entire framework is tailored to meet the specific needs of your company.
That’s a smart approach. What tools do you use to manage risk and compliance at Atlassian?
George: Initially, we looked around at a number of Governance, Risk, and Compliance (GRC) systems. We knew we had to use a system — we could not manage using spreadsheets and documents.
As we researched it started to dawn on us that we had all the tools we need to build our very own GRC system right here, using Atlassian’s own products. So, with a little creative tinkering and specialized integration — using Confluence for documents and Jira for workflow mapping and tracking — we built an extremely powerful GRC system that not only addresses our needs. but also tightly integrates with the rest of the organization.
It started to dawn on us that we had all the tools we need to build our very own GRC system right here, using Atlassian’s own products.”
Agile development and DevOps teams rely on a culture of trust and collaboration, which may mean just shipping software without worrying about a regulator’s checklist. How do you reconcile this desire to get to market fast, while still shipping safe software?
George: It’s true, a lot of companies are struggling to reconcile the principles of Agile and DevOps with their compliance responsibilities. There are obviously a lot of benefits in those approaches for software development and release. The problem is that when you show the Agile Manifesto to an auditor, and they see that first line about no documentation, they have a heart attack! Auditors are used to looking for documentation.
Going back to our core philosophy, we don’t do documentation for the sake of documentation. Documentation is used as evidence for certain risk management practices. If there is another way to evidence those practices or automate evidencing, then we must explore that. And yes, you have to work with your compliance team, legal team, auditors, and developers to come up with an approach that satisfies the requirements for all of them. But we shouldn’t be afraid to question how things have been done before.
What unexpected traits do you bring to this role?
George: My wife would say I have a gazillion useless facts in my head that I can always bring to bear. But I would say it’s my curiosity. Not everyone in this work appreciates the value of asking questions before you lay down new rules. One thing I’ve learned in all these years is that we have to approach an existing organizational culture with curiosity, rather than try to impose something on it, in the name of risk and compliance. Because the moment we try to force something is the moment we fail.
One thing I’ve learned in all these years is that we have to approach an existing organizational culture with curiosity, rather than try to impose something on it, in the name of risk and compliance. Because the moment we try to force something is the moment we fail.
What do you foresee as the near-future priorities for your team?
George: Privacy will be a stronger factor in our risks analyses. In a way, GDPR turned every SaaS company into a regulated company — a completely different paradigm for the majority of us. We have to be cognizant of “check-the-box” compliance and see if we could repurpose practices we already have.
Having achieved a solid compliance baseline with SOC2/ISO27001/18, we will be looking at some more tailored standards and controls that will help our customers achieve their compliance.
We want to be very open about our philosophy, practices, controls, and approaches to managing risk. Expect us to be more active in sharing these at conferences and in white papers and blog posts. It will help people better understand us, and how we help them manage risks. It will also help us understand our customers, so we can continuously improve. Our goal is to be a step ahead of customers in managing risk, so they can trust us with their data.
Learn more about security and compliance in our Data Center and Atlassian Cloud offerings.