Technical Compliance - Enterprise Security beyond silos, gimmicks and paper shields

This is an intermediate level Wiki article about Information Security compliance. The InfoSec vs. Compliance FAQ section at the end is opinionated as well.
Sub-sections deal with the integration points between an ISMS and Agile. And a gap analysis points out what ISMS systems aren’t good at unless they get extended. Last but not least there is a high-level summary.

Technical Compliance - Enterprise Security beyond silos, gimmicks and paper shields

In Information Security you may encounter people with a sporadic interest. After all military-grade Cyber-operations make it to the news; if their success is limited. – Still, it’s safe to say that there is some level of (public) interest.

In private businesses, on occasion, a sporadic suggestion may come from top management and it may concern a new kind of security product. Maybe the Gizmo-gimmick 2.0 from Whizbang. Maybe your CTO heard about this from his contacts at He-Man Brothers, from back in the days. What’s a good reply to the question: “Do we need Gizmo?”

The good news: if you have got an ISMS you can probably provide a structured answer to which degree Gizmo-gimmick 2.0 can reduce the risks.

The bad news: not only do you need to find out what a Gizmo-gimmick 2.0 is, you may also have to learn about Information Security Management Systems. And when you are done Gizmo-gimmick 2.0 may be out in version 3, He-Man Brothers may have merged with Whizbang Inc. and you have to start from scratch again.

But in order to make sure that this doesn’t happen, this guide has been kept short and simple.

Technical compliance is not a Ph.D. thesis and the simpler an ISMS is, the better it works; at least in my experience.

– If you really want to stretch it: knowing what all these tech gimmicks do isn’t your job if you are to maintain an ISMS as the (Chief) Information Security Officer (ISO). It may be surprising, but technical dimensions don’t need to be dominant in this area or field of work. It’s not a technocracy. I understand some techies want that. I also understand some paper-pushers don’t. Be careful and don’t create a mess or a paper shield.

What's a paper-shield?

Greedy businesses may follow the pirate toast: “Take what you can, Give nothing back” (Jack Sparrow, Pirates Of The Caribbean).

Even certain stock-traded companies[1] are indistinguishable from pirates, and transparent self-regulation doesn’t work everywhere. You know… “Betrayals start that way, with lies hidden in the shadows of silence.” (Don Winslow, The Cartel). Or in other words: in compliance, you may be the last one who finds out.

Compliance has the high-level obligation to advise (the board) on setting up global ethical standards within the organization(s). Consumer protection[2], for example within the GDPR, is one of the topics in global compliance. In Germany, we have the DCGK[3]. Is that a paper shield?

Reciting standards and making a couple of lifecycle illustrations doesn’t make much of a manager. Or a “purple teamer”. Or a professional. It makes a paper shield (as well).

What is a Management System - misunderstandings that lead to understandings

An ISMS doesn’t imply that a company’s / institution’s products or even procedures are “secure”. It just means that there are select structured approaches for information security with a certain scope. – That there are risk-based management approaches.

There may be gaps, and there may be misalignments. Ineffective controls… auditors can tell you stories. The ISMS is about continuous improvement.

So many standards, so little time - are they all the same?

Consider that multiple approaches towards an ISMS approaches exist, for example:

  • IEC / ISO 27001 (the international norm),
  • DIN ISO 27001 based on BSI Standards[4] (200-x, a federal German ISMS standard),
  • German VdS 3473 / 10000 (often referred to as TISAX, an industry-specific ISMS standard) or
  • even the “Bavarian” ISIS 12 (a ISMS standard for Small-Medium Businesses)

– These four standards allow an organization to develop an ISMS that’s certifiable by accredited auditors following the guidance of a certification body.

– All of these are information security management system models. Just models. Some more detailed than others. The level of freedom an organization maintains may be different.

– They are not totally distinct from each other: you can implement measures of ISO 27001 Appendix A with BSI recommended measures, and you will still be in line with the best practices within ISO 27002. Depending on your certification objectives the BSI standard may not be binding for you, but you can cross-reference best practices that should not differ. In other words: if you need more guidance, cross-check the other ISMS standards. Especially if you are new to this.

– In ISO 27001 you are free to decide whether you want to use a two-step Risk Assessment approach from BSI 200-3 (first use the blocks (Modeling) then focus on extraordinary and individual parts), ISO 27005 or ISO 31000 others. That is up to you and your organization. You may even consider using FAIR.

– It may not always be a requirement that you have an ISMS that can pass a certain certification audit. If you implemented one part (let’s say Information Security Risk Assessments) that can be understood as an ISMS already. But that isn’t complete.

The most essential commonality across all ISMS standards

Implementing an ISMS with any of these models is a business operation [5] concerning an entire organization[6].

Yes, you can set a scope (Scope of Applicability / SoA) but scope decisions may be impactful for the entire business.

What about Hackers? Threats that lead to improvements

Unfortunately even hackers / cyber-criminals are hard working professionals nowadays.

Some Ransomware is well-tested software, and paid developers work in teams. They may even have managers and reporting.
– Surprising, but let’s be real. It’s all about the money. Many institutions and companies get hit by Ransomware, and that not because they “are dumb”.

The German BSI sometimes emphasizes that private sector companies focus on their organizational maturity and implement (cheaper) organizational measures. Like processes and procedures. Later security measures may be technical installations.

The logic behind this: what good is the newest → gimmick without skills and concepts? And why do you need that gizmo that defends your business against space lasers, when you are vulnerable to some misguided teenagers nicking some of your fancy laptops for a quick buck, and when you lose business-critical information in the process of that? What’s more important now?

Can an org be Agile and have a healthy ISMS?

I don’t know why some orgs have huge rifts between their compliance org and their DevOps org. There are effective solutions if you aren’t too thick on both ends. Take it easy… simple and lightweight.

Conflict Management and authority in Agile orgs

Today an effective compliance org adopts Agile methods (we have yearly re-audits and iteratively account for improvements…). In Agile orgs we may not have “authority”. In fact, as a (C)ISO [7] you consult the organization and you are not the decision-maker.

– Rather than emphasizing the R in a RASCI matrix check out the Drive - Approver - Contributors - Informed matrix[8] and whether you can work without authority-based delegation. Working without authority is a key skill in companies with flat hierarchies.

– Minimum Viable Prototypes (MVP) and iterative approaches(!): if used correctly these avoid stagnation (incl. outdated policies and procedures). More on that in the following. Stagnation is bad for everyone.

(!) Security tools with incremental result updates (and reporting) are expensive. Since DevOps as a tech consolidation scheme, you may find that it also produces hidden costs. Don’t move these costs into your security org without making this clear. It’s not the developers’ fault that this is expensive. It’s no one’s fault at all. Things cost money. That’s business.

But this slows down DevOps!

DevOps can be like quantum physics: looking at the quant changes it. Don’t look at DevOps. It may get slow!

First of all: an ISMS doesn’t slow down “DevOps”. I see DevOps is a tech org consolidation scheme. Consolidation for the sake of speed, maybe. But maybe it’s just cost reduction. Maybe DevOps is just a buzzword that’s got nothing to do with Agile?

– DevOps / Scrum / … doesn’t directly affect the ISMS, which remains neutral here. What concerns the ISMS is that semi-agile companies may build RASCI[9] matrices to manage stakeholders (4.2). That’s challenging for Agile / agile tech orgs.

Mostly because Responsibility tangents the internal / external topics of ISO 27001 (4.1) but this is not directly within the 12 Principles of Agile software (PMBOK[10]) which can generically illustrate software engineering workflows.

Agile doesn't mean working without rules

Agile isn’t chaotic engineering. A aforementioned DACI approach lends itself well to the actual Agile principles:

Recap: 12 principles of Agile Software (PMBOK)
  1. highest prio is to satisfy the customer via early and continuous delivery of valuable software...
  2. welcome changing requirements even late in the development process
  3. deliver working software frequently
  4. business people must work together throughout the project
  5. build projects organically around motivated individuals
  6. the most efficient info-sync is in-person
  7. working software is a primary measure of success
  8. Agile processes promote sustainable engineering practices
  9. Continuous approaches limit technical debt for continuing agility
  10. Simplicity over complexity
  11. best designs, architectures and requirement analysis result from self-organizing teams
  12. regular reflections within the team promote a healthy environment

It’s very well possible to adopt the best parts from Agile methods and the lessons contained within Security and Compliance standards.

– What this requires is that you keep things simple. DevOps is a lot of things, but there is no one and only DevOps Standard. – Maybe that’s for a reason? As a side-note: in my experience developers can be resistant to training options (seminars etc.), and instead, continue to build up knowledge bubbles. These can burst if they / we don’t work cross-functionally while building up domain expertise.

Loose terms that lead to ideas on how to have both: DevOps and a healthy ISMS
  • Blue / Green Deployments with approval based switches[11]
  • Automated ticket generation within the Pipeline[12]
  • Code management workflows (merging changes to a “master” branch) with Peer Reviews[13]
  • Continuous Integration for security tools(!)

(!) Most security tools are not ready for this in 2021. Sad, but true. You need to carefully evaluate the tools and some vendors have setup presales traps where the tools only work until you purchase them. Be careful. We live in an era where it’s like this.

And what about "developer" privileges?

Please refer to this article about “Access as a process”.

And what about continuously changing assets?



On more serious terms:

– Solutions here may require investments. In the past I came across IT asset catalogs with difficult integration options. The overall situation has improved very little.

– “Asset management” actually is a finance term I associate with investment management and fiduciaries.

– Many compliance professionals don’t know why there needs to be an ISMS asset management process in the first place. In most cases, grouping assets is key, if there are commonalities including the risk exposure. This is also one of the reasons why technical compliance needs to remain distinct from IT. Compliance doesn’t create network topology diagrams. Or any technical documentation.

– True, there need to be finance workflows to depreciate assets. Also true, this doesn’t concern these Pods and Containers. So what about these continuous assets? Let them be continuous. In the end, they reside on a procured hardware, on which there are virtual / software systems.

And what about Change Mana Mana Management

The core idea of DevOps is to be “continuous” by breaking down impactful changes into multiple increments. This way deployments become controllable and it’s easier to develop software at scale.

Compliance is not the mini-change police, because the first and foremost goal of change management is to build approval chains for those changes where it matters.

Proportional change management can focus on non-standard changes on a Story level, and (pre-)approve them.
Depending on the exact requirements (incl. regulatory constraints) this may be sufficient if the related standard changes are automatically tracked within the Build, Test, Release, Deploy cycles. To a certain degree, this can be automated.

– Checkout deployment schemes like Blue-Green deployment. Why approve changes too early, when you can control and approve which deployment goes live and use the change tracking and pre-approvals to evaluate that? Why not handle approval in stages?

How do you start an Information Security Management System

As indicated before, that’s the easy part (an opinionated estimation may be that this is about 20% of the work). Depending on the size and complexity of the org this may take months or even years before you are ready for a certification audit; if that is the goal. At this point, this little Wiki essay should have disillusioned even the most avid junior consultant that technical compliance is good for entry-level jobs.

If the image below doesn't load

There are too many books and courses about the topic, but I think they all agree that top management is the start point. That doesn’t imply that top managers must become Information Security Officers. It just means that they must be involved. – Not just for the first steps, but also for regular management reports and risk mitigation decisions.

Involving top managers into risk workshops should not be difficult, because depending on the company corporate law may require a yearly global risk review. In Germany that is the case for incorporated organizations. And no, I wouldn’t start an invitation by quoting the law… I am just saying that it should be relatively easy if you have good communication skills.

A list of documents and what they mean for an organization

Here’s a brief list of documents that need to be considered if you plan to certify an ISMS under IEC / ISO 27001. What good do these documents do, if you follow the best practices?

ISMS org setup table I - init

This is complete to the best of my current knowledge:

ISO 27001 clause Short Related
5.2: IS politics Risk reduction objective(s)

Corporate Social Responsibility
declarations / creation of an organization
(with Information Security Officer)
4.2: Scope of the ISMS Entities / sub-entities
Inter-company agreements
Org structure
Scope Of Applicability needs to be adequate
6.1.2 / 6.1.3; Risk Process Risk Management Process Risks and treatments (compensating controls)
6.1.3 d: Scope Of Applicability Coverage of ISMS and controls For your B2B suppliers check
the SoA as well as the ISO 27k certificate

This table is opinionated.

What do these strategic ISMS documents do?

– On their own, nothing. Especially in context of an ISMS, which contains policies, procedures AND practices. Practices can be assessed onsite by auditors.

On a strategic level these documents formalize the security organization:

1.) 5.2 → Management decides to reduce the risks and takes responsibility to support the security organization in the process of that.
2.) 4.2 → The security organization has a scope
3.) 6.1 → The organization has a general approach on how to deal with risks, and how they assess risks.

Again: on their own these documents do nothing. But in the context of management engagement these agreements initiate a Plan - Do - Check - Act cycle that’s beyond a paper shield. These documents need to be written in close cooperation with top management and they need to be well formulated. But once you have done that, your security organization may have a foundation.

Details of transparent self-regulation in information security orgs

Transparent self-regulation means that you need to create transparency first, and that’s what the next documents are all about. What good is regulation, if it’s based on hearsay?

ISMS org setup table II - init of self-regulation
ISO 27001 clause Short Related
9.3: Management Review Formalized meeting with notes Often called “Information Security Forum” (ISF)
; according to ISO 27007 A.3
7.2 d: Competences Auditable competences Declaration of security officer
Dedication of resources (auditable)
7.5.1: Policies Auditable documents Needed for Stage 2 already:
policy framework for the ISMS scope,
in line with IS politics
8.2: Risk Assessments and results Conducted InfoSec Risk Assessments Filed risk assessments (document control applies)
Results appear in a Risk Register (with assignees,
owners, approvals etc.)
Assets have defined risks
8.3: Risk Treatments Plan of risk treatments (in place) Org treats risks in accordance to IS politics,
policies and procedures

Risk Register associates identified risks with treatments
documented Key Performance Indicators Documented KPIs ISO 27k does not declare which KPIs you must measure. Good KPIs may include relevant risk areas such as identified non-conformities during Access Management review (policy violations) or inappropriate changes to the environment in scope (Change Mgmt - missing approval / business reason). → Quality Management
10.1 f Treatment Plan Plan for controls Project Management level plan for control implementation
10.1 j Results of the corrective actions ^Definition of Done for project to implement control; under- or over-controlled scenario adjusted

4.) 9.3 → a regular meeting with management, forming stakeholders. This is business communication
5.) Competences → who is able to perform information security duties?

A very simplified PDCA cycle for an ISO 27001 based ISMS could arrange the clauses this way:

If the image below doesn't load

The gist of this is: don’t start with writing the policies. As tempting as it may appeal to you. It’s not the right way. You may start with getting into the business:

  • integrate with Global Risk Management, OKR processes, find out about the cash cow and where the core business is. That’s what you are there to support and to protect.
  • It’s not about establishing a technocracy… but also it’s not about blocking innovation with bureaucracy. Companies, especially in Germany, need to innovate.
    • Policies are only as good as your understanding of the business. That’s why you should not just download them from the internet or from some random GRC tool.

Keep in mind: an ISMS is about risks AND chances.

ISMS policy and procedure framework

ISMS org setup table III - policy and procedure
ISO 27001 clause Brief description
18.1.1 Contractual and regulatory requirements
→ example: IDW standard applies for some systems if the Org is stock-traded, PCI DSS is a contractual requirement based on the Merchant Agreement
18.1.2 Intellectual Property / Trademarks / … patents
→ account for an appropriate level of protection
17.1.2 Business Continuity Management (BCM) aspects of Disaster Recovery related to InfoSec
17.1.3 Resulting Business Continuity Plan (BCP) with derived Recovery Point Objectives (RPOs) and Recovery Time Objectives (RTOs) at least. Usually done based on a Business Impact Analysis (no formal requirements within ISO 27k)
16 Incident Management and Incident Response
Alerting procedures and responsibilities (OnCall / SoC / …)
Crisis Management
15 Supplier Management policy
→ 15.2 Information Security assessments of suppliers (in line with contract management)
14.2.1 Policy for secure software development (high level)
→ 14.2.5 Baselines for hardening
13.2.1 Policy for information transmission over networks
13.1 Some level of network diagram (boxes and arrows may suffice)
12.1.1 Documented procedures / handbooks
12.3 Security Policy (in line with IS politics)
12.4 Event protocols (some level of log management)

Many coworkers don’t read these policies and do not know where to find them. Unless they read my Email, that arrives one day before the audit. That falls under awareness training as well.

On more serious terms: I fully empathize with the fact that facility managers or even software engineers do not know about the accountability measures for patent protection measures… We need to break things down, and realize what matters to them.

When compliance is not a law

There are certain technical compliance areas, where a flexible and effective strategy is appropriate. There are others where it is not proportional.

IT Governance: compliance of IT systems related to the annual finance report

Compliance is often used in conjunction with IT Governance functions concerning business reporting in incorporated companies for example.

The relevant standards in this domain are national. In Germany, it’s the IDW standards[14]. Based on these standards[15] certain accredited auditors would conduct yearly IT audits, related to the finance report. Most IT directors are familiar with the process.

Requirements from IDW standards may get reflected in an ISMS. Charted auditors[16] would recommend COBIT to set these control objectives. Internal control systems based on COBIT can coexist with an ISMS. In practice, it’s not overly difficult to combine the reports even, because ISO 27001 is relatively flexible. But here and there people tend to blow things out of proportion.

In Small-Medium businesses, you will not find much of COBIT or ITIL, because these Enterprise standards are a little overkill there. What is important is, that you keep in mind that these “finance” systems are supposed to be secured and managed in accordance with the ISMS policies and procedures and that they are not out of scope for an incorporated company. Even if they are outsourced, in the Cloud[tm] or “already audited”.

Contractual: Cyber-insurance policies and operational-breakdown insurance

An organization that applies for cyber insurance (incl. insurance against operational breakdown, possibly caused by Ransomware) will have to undergo an assessment. Insurers are well versed in quantifying the risk that customers want to transfer. Within the Cyber-insurance questionnaire, you’ll most likely see paragraphs concerning the security posture from a compliance perspective.

Obviously, an organization will have to prove responsible decision-making once they have to file an insurance claim. An ISMS is ideal for that, assuming that the controls haven’t degraded. Initially, it even helps to identify those risks, where financial constraints may indicate opportunities for risk transfers. – Keep in mind that these transfers may not need to be permanent.
Once the transfer has been formalized with an insurance policy, there will be contractual information security obligations as part of the risk transfer.

– Divestment that leads to under-controlled scenarios can be troublesome. Due to this, it is important to document such risk transfers in an ISMS risk register. These transferred risks remain in scope.

– For many Small-Medium businesses cyber-insurance is too expensive, and often the insurance costs more than their security program. – A good indicator that there’s something wrong is, that no one wants to ensure you, right?

Data-privacy: GDPR Technical Organisational Measures

On an objective level data protection and information, security share some commonalities, but information security isn’t centered around data-subject rights. Usually, you find the ISMS ISO 27k referenced to account for Technical Organisational Measures (TOMs). A detailed mapping between the clauses and the paragraphs has been created by the IAPP.

IAPP-OneTrust-Bridging-ISO-GDPR-final.pdf (opinionated)

– In case the GDPR related measures are being implemented and maintained via an ISMS these select controls become legally binding. That does not mean that ISO 27001 compliance is legally necessary. It just means that the control system, certified or not, must ensure the status of these select controls as far as they relate to the GDPR.

– For Data Privacy Management Systems that have more connections to an ISMS there is the ISO 27701 for privacy information management.

Gaps in ISMS

We should be aware of gaps in ISMS, which may introduce hidden risks to the organization that relies on the ISMS providing 100% 360° degree coverage.

GAP: Vague software-security controls

In any of the ISMS standards mentioned in this WIki article the referenced software security controls are vague at best. That is astonishing if we consider that every company nowadays deals with software.

Illustration of the compliance system problem with SQL injection

Let’s say a web app that processes some personally identifiable information is vulnerable to SQL injection. That means a loss of confidentiality, and maybe integrity if you can alter the data. Maybe even to availability if you bring down the app this way. Total loss.

It’s not that there are no classification standards for these kinds of software issues:

Item Short issue description Reference Common impact criteria Common likelihood criteria
Coding Standard Trust in user input IDS00-J. Prevent SQL injection Confidential data / Private Data, Compliance regulation, Business data Encoding, amount of Entry Points
Audit item User Input handling CWE-89, CWE-564 Sanitization, Normalization, Filters, WAF, DLP, IDS / IPS, … Data breach statistics, Risk Assessment / Threat Model
Pentest item Injection of arbitrary query string A1 Injection Access level, vertical escalation, integrity loss -

– Practically you can set up a scoring system for those web apps in an ISMS scope, and agree with development that a score larger than 100 for example requires immediate attention. And this kind of issue would score over 10000.

– At the moment there are no general software security scoring standards apart from some commercial initiatives which may be costly.

Development life cycle approaches to software security

– Commonly you’d reference an Application Security control or even a program based on Secure Development Cycles (SAP, MS SSDLC, …)

The reality is that someone took the Waterfall model and connected the start to the finish here. :slight_smile:

GAP: Cloud-operation security

Cloud Computing is defined by NIST[17], and that’s where the terms public cloud, private cloud, and so on come from. For a long time ISMS standards were known as blockers for Cloud projects, but usually for unclear reasons. Often the projects would avoid making concepts, plans and looking at these ever-changing cloud solutions and just try to migrate into the blue.

If you are interested in the extension of an ISMS that features cloud computing controls, check out ISO 27017. You can get ISO 27017 certified if you are ISO 27001 certified.


This is not the most formal article about compliance management. I have successfully avoided ties for the last couple of years. Safe to say I will manage to continue this way.

  • there are multiple ISMS standards for different companies, industry sectors and countries
  • all ISMS are about continuous improvements and risk reduction
  • Agile / DevOps / … and a certified ISMS can be integrated and doing this at scale costs money; like everything you do at scale
  • you should look beyond ISO 27001 for data privacy controls, cloud computing or software security
  • paper-shields are not necessary
  • an ISMS doesn’t imply any particular level of security

InfoSec Compliance FAQs

Here’s some Q&A. Over the years I have come to the conclusion that many technical-minded people use the exclamation mark and the question mark interchangeably. :exclamation: :heavy_heart_exclamation: :question:

Isn't compliance just duct-tape for InfoSec?

Is involving top management necessary? – Certainly, otherwise getting resources may become impossible. Compliance helps to archive that. Is Compliance the answer to inherent technical information security issues? – Absolutely not.

Compliance in InfoSec means to mind and support business objectives in conjunction with security goals and processes.

Not all compliance advice seems to make sense!

As a Subject Matter Expert, you can always get involved. Some areas have little flexibility, and regulators may even prevent certain modern approaches.

As a Computer Scientist, I can also sometimes think of better solutions that certain compliance prescriptions have to offer. It’s also possible that the compliance organization isn’t diplomatic enough. The problem is, that regulators and courts can be even less diplomatic. And that their advice is binding.

Auditors don't seem to be very thorough / skilled!

Auditors are usually neutral and audit the conformity to a certain standard (ISO 17021). In InfoSec they do not audit for quality-related issues.

Sometimes engineers may be under the impression that a lack of quality must lead to an audit finding when it actually doesn’t need to. I have met auditors, who were new at their job. That’s ok. They don’t need to be more skilled than seasoned (C)ISOs.

Isn't all this awareness training a waste of time?

Jupp. If I can I prefer social engineering penetration tests with a rewards system for those coworkers who defend the org successfully. Maybe only the rest should have to attend the awareness training sessions?

Is compliance the reason that I as an engineer cannot get local admin rights?

Depends… I know some compensating controls for that, that work as long as you don’t need to work with customer data. Getting these controls in place and audited repeatedly is effort for a compliance organization. Did you ever try to help?

Sometimes I have the feeling that the ISO / compliance team isn't as technically skilled as I am!

When I was working as a software engineer I knew more about C++ than today. Safe to say, if you work as a software engineer today, you are more skilled in C++ than I am. Hopefully.

That being said, the amount of technical expertise in InfoSec compliance as a whole could be higher. How good are you at explaining things? Besides that, in a compliance org there may be lawyers and regulation experts. They don’t intend to become as technically skilled as engineers. Your feeling may be right.

My feeling sometimes is, that certain techies in certain companies know very little about the industry sector they are in. The Volkswagen test has become a popular industry term, hasn’t it?

How can org X be compliant if their level of security is low and their security team repeatedly highlights severe security issues / risks?

They probably aren’t.

Nowadays times are sophisticated: some orgs go through (regular) merger and acquisition changes, mostly to pretty up the balance sheets and to improve the investor relations portfolio and the ratings. This also shifts a lot of assets back and forth. – Assets, that have risks associated with them.
That means that the clocks are ticking when it comes to information security compliance, but you don’t have to immediately treat all the “new” risks. Yes, this is a form of accumulation of technical debt. No, it’s not necessarily a compliance issue. Unless it’s able to cause severe damage to one business, leading to an existential disruption. That’s another story and beyond InfoSec compliance.

Can a 1-person org get ISO 27001 certified


More questions?

→ You may contact /me.


2021-05-28T22:00:00Z - fixed grammar and typos

  1. Wirecard - Wikipedia ↩︎

  2. In the GDPR this concerns data-subjects ↩︎

  3. Home - dcgk - englisch ↩︎

  4. BSI - IT-Grundschutz ↩︎

  5. a project as defined by PMBOK with a start, end, and resources plus following maintenance (which is 80% of the effort) ↩︎

  6. company, group entities, subsidiaries, contractors, … ↩︎

  7. ISO is also defined here as a contact point (German TKG § 109 Abs 4). But even if you are a board member and CISO you don’t get magic powers. ↩︎

  8. Results without authority: controlling a project when the team doesn’t report to you. A - Tom Kendrick ↩︎

  9. Responsibility assignment matrix - Wikipedia ↩︎

  10. The misunderstood Waterfall-approach that influenced both tech and compliance for decades is from a PMBOK issue (70ies / 80ies). ↩︎

  11. Blue-green deployment - Wikipedia ↩︎

  12. A beginner's guide to building DevOps pipelines with open source tools | ↩︎

  13. Git - Basic Branching and Merging ↩︎

  14. IDW ↩︎

  15. IDW AuS 330 (Annual IT Audit for annual accounting) and PS 880 (Audit of software products) ↩︎

  16. DE: Wirtschaftsprüfer ↩︎

  17. SP 800-145, The NIST Definition of Cloud Computing | CSRC ↩︎