<p>In my experience auditors tend to follow a <a href="https://en.wikipedia.org/wiki/SOX_404_top%E2%80%93down_risk_assessment" rel="nofollow noreferrer">Top-down Risk Assessment</a> process whereby they review the <strong>inherent risk</strong> to business and IT for a company or system, then look at the <strong>controls</strong> that company has in place to mitigate the inherent risk and the <strong>residual risk</strong> that remains.</p>

<p>A top-down risk assessment opposes the way most technical people work, in that we look at specific vulnerabilities, defects and design flaws and then work up from there in a more bottom-up approach.</p>

<p>There is nothing inherently wrong with either approach they both have a place in any given company, so in answer to your questions:</p>

<ul>
<li><p>Auditors do not tend to ask domain-specific questions such as <em>Have you checked your API for OWASP breaches</em>; they do tend to ask questions such as <em>What controls are in place to mitigate the risk of data loss due to software vulnerabilities?</em></p></li>
<li><p>The thing to realise about ISO 27001, and most standards, is that they are not prescriptive - they are designed to provide a standard business language to enable communication between Business/IT and Auditors.  More often than not "implementing" any standard is about identifying the <strong>existing processes</strong> that meet the requirements of the standard and documenting them, then looking for any gaps or flaws and plugging the holes.</p></li>
</ul>

<p>The same logic goes for ISO 9000, ITIL, COBIT, COSO, etc. it's very rarely about enforcing some pre-defined process. Instead, it is a case of <a href="https://www.devopsgroup.com/2018/04/10/journey-iso27001-importance-devopsguys/" rel="nofollow noreferrer">creating a mapping</a> between what the auditor is looking for and what the business is doing.</p>

CC BY-SA 4.0
2018-12-05T11:22:47.237Z
hi @Richard, thanks, so this sounds at first hand that DevSecOps can be "invisible" in the audit context. To be more specific, in the question "what controls are in place to mitigate the risk of data loss due to software vulnerabilities", what is the reference to the software delivered to customer, i.e. protecting customer data loss? Otherwise, the responsibility is moving to the audit at customer place.
Ta Mu
CC BY-SA 4.0
2018-12-05T14:16:39.830Z
In theory, it should be invisible, unfortunately, it usually takes quite a lot of explaining to both internal and external audit because you are breaking their mental model of what is "right and wrong".  You also need to take the whole system into account, known as Systems Thinking, as for example an auditor might highlight that a Change Management for code moving into production process is ineffective because it dosn't require human intervention - you then have to articulate that the "second pair of eyes" has shifted left to the development stage via Pull Requests or Pair Programming.
Richard Slater
CC BY-SA 4.0
2018-12-05T11:16:40.420Z
2018-12-05T11:16:40.420Z
Richard Slater
<p>Correct me if I am wrong, ISO 27001 addresses mostly organizational and operational aspects. This sounds a little bit abstract and regulatory.</p>

<p>On the other hand, in DevOps, if you wish DevSecOps, there is proactive and very specific demand for processes and tools to ensure that no vulnerabilities are delivered to customer. </p>

<p>How do these two domains fit together? </p>

<p>Do security auditors ask actually in a security audit questions like,</p>

<ul>
<li>"Do you have a vulnerability scan as part of your component dependency management?</li>
<li>Have you checked your API for OWASP breaches? </li>
<li>Do you scan your Docker images, being aware of risks connected to base images?"</li>
</ul>

<security><audit>
Context of DevOps in ISO 27001 security audits
Ta Mu
# Context of DevOps in ISO 27001 security audits

(Asked by: username_0 on 2018-12-05)

Correct me if I am wrong, ISO 27001 addresses mostly organizational and operational aspects. This sounds a little bit abstract and regulatory.

On the other hand, in DevOps, if you wish DevSecOps, there is proactive and very specific demand for processes and tools to ensure that no vulnerabilities are delivered to customer.

How do these two domains fit together?

Do security auditors ask actually in a security audit questions like,

* "Do you have a vulnerability scan as part of your component dependency management?
* Have you checked your API for OWASP breaches?
* Do you scan your Docker images, being aware of risks connected to base images?"

**Tags:** security, audit


---

## 1 answers

### Answer by username_1 on 2018-12-05. Score: 2

In my experience auditors tend to follow a [Top-down Risk Assessment](https://en.wikipedia.org/wiki/SOX_404_top%E2%80%93down_risk_assessment) process whereby they review the **inherent risk** to business and IT for a company or system, then look at the **controls** that company has in place to mitigate the inherent risk and the **residual risk** that remains.

A top-down risk assessment opposes the way most technical people work, in that we look at specific vulnerabilities, defects and design flaws and then work up from there in a more bottom-up approach.

There is nothing inherently wrong with either approach they both have a place in any given company, so in answer to your questions:

* Auditors do not tend to ask domain-specific questions such as *Have you checked your API for OWASP breaches*; they do tend to ask questions such as *What controls are in place to mitigate the risk of data loss due to software vulnerabilities?*
* The thing to realise about ISO 27001, and most standards, is that they are not prescriptive - they are designed to provide a standard business language to enable communication between Business/IT and Auditors. More often than not "implementing" any standard is about identifying the **existing processes** that meet the requirements of the standard and documenting them, then looking for any gaps or flaws and plugging the holes.

The same logic goes for ISO 9000, ITIL, COBIT, COSO, etc. it's very rarely about enforcing some pre-defined process. Instead, it is a case of [creating a mapping](https://www.devopsgroup.com/2018/04/10/journey-iso27001-importance-devopsguys/) between what the auditor is looking for and what the business is doing.

> **Comments:**
> **username_0**: hi @Richard, thanks, so this sounds at first hand that DevSecOps can be "invisible" in the audit context. To be more specific, in the question "what controls are in place to mitigate the risk of data loss due to software vulnerabilities", what is the reference to the software delivered to customer, i.e. protecting customer data loss? Otherwise, the responsibility is moving to the audit at customer place.  
> **username_1**: In theory, it should be invisible, unfortunately, it usually takes quite a lot of explaining to both internal and external audit because you are breaking their mental model of what is "right and wrong".  You also need to take the whole system into account, known as Systems Thinking, as for example an auditor might highlight that a Change Management for code moving into production process is ineffective because it dosn't require human intervention - you then have to articulate that the "second pair of eyes" has shifted left to the development stage via Pull Requests or Pair Programming.  

---

