TÜV certification: an interview on Trusted Development

The TÜV certification is based on national and international standards, specifically on the approaches of the following:

• BSI study "Durchführungskonzept für Penetrationstests"

• NIST SP 800-115 "Technical Guide to Information Security Testing and Assessment"

• ISO/IEC 27001 "Information security management systems"

• ISO/IEC 27002 "Information technology security techniques"

• ISO/IEC 27033 "Information technology – Security techniques – Network security"

• BSI IT-Grundschutz

• OWASP (Open Worldwide Application Security Project)

These standards, however, are each geared toward a specific topic on the one hand, such as security management, while on the other hand they're also framed much more broadly than just the development of applications, which is our core business.

So the TÜV certification essentially follows a best-of-breed approach and draws on the methods of established best practices. From these, the TÜV auditors developed a certification that checks exactly the parameters that matter specifically in our business.

Ultimately, it's about trust for us. Because trust is a decisive factor in the run-up to an emerging IT project. There are a great many service providers in our business. And of course everyone claims to know their craft, perhaps even better than the competition. Usually, reference clients get to speak in this context to back that up. That's important and right, and we're glad to hear kind words too. But it mattered to us to earn this recognition from an independent testing body like TÜV, which above all examines methodology and processes. The certification is the proof: our way of working meets the very highest standards. That's another building block for building trust. And trust is a decisive factor in the run-up to an emerging IT project.

Over the years, across a wide range of client projects, we've established standards, for example the way we gather requirements and turn them into software development. TÜV examined these processes and confirmed that the Shopmacher development standards align with overarching conventions, such as the agile frameworks Scrum and Kanban. We also described the conditions under which one agile framework is preferable to another. That this works for us was already clear to us beforehand, which is exactly why we work this way and no other. That the nuances we developed for ourselves between the well-known frameworks are even considered a benchmark for the industry surprised us in part, and makes us a little proud too.

It varies a lot. But let's take the whole requirements-gathering process again as an example, when a client comes to us with a wish. Our process is designed so that we don't simply implement it, not even when it's already very well prepared and specified. There's a simple reason for that: we usually work with our clients for months, often years. Before we program anything, we need to understand the context, the goal, the business behind the requirement precisely. Because concrete requirements often change over the course of the collaboration, and then shared priorities and decisions have to be made. For that, we need the business context, so we can then advise and implement appropriately.

If you look at the marketing of IT service providers, most of them claim they want to understand the client. What else? But we don't just claim it, we can demonstrate a procedure for initiating projects that proves how and why we do it. That kind of thing is rated positively in the TÜV assessment, and you lose points if you can't back up a claim.

When it eventually moves into implementation, we work in an agile way: backlog > epics > user stories > acceptance criteria > test-driven development > client sign-off > deployment > automated testing.

You'll find these buzzwords as bullshit bingo in the marketing of almost every IT service provider. "Agile" is on everyone's lips, from the dog-training field to the dance contest. But in IT there are very concrete work steps behind it that must be followed for good reason. If you don't, your lip service will blow up in your face at the latest during the TÜV assessment.

When standards work (which the certification confirms), you work more efficiently. As a rule, service providers like us calculate effort times day rate. As a client, you therefore have a certain assurance that the effort was estimated reasonably realistically and that there's little friction when the procedure is standardized.

And documentation is part of standardization too. It's a topic that tends to get neglected at a lower level. When a project eventually needs to be handed over, migrated, or otherwise understood by an outside party, you run into problems without documentation. Not if you stick to standards.

"Assurance" is perhaps the wrong word. But at least a higher probability that professionals are at work here and that the conditions for excellent implementation are in place. As someone responsible for IT, you need solid criteria for allocating budget. That it can't be about price alone is surely a truism. It's always about quality too. But what should you use as a reference? A certification is an independent mark of recognition.

Yes, it really was! We were given nothing for free.

In practice it was like a tax audit. The auditors requested documents in advance according to a checklist, prepared themselves, and then questioned us here on the topics they couldn't directly follow based on the documents provided. Then, at some point, the result came in.

The biggest challenge was certainly to supply as many of the requested documents as possible in advance. We had documented many of our processes, if only for onboarding new employees, but we're not a public authority either. Some things here still ran on an informal basis. On those points, we actually got even better through the assessment, because we now document even better.

Interestingly, the auditors also confirmed that we don't have to cast everything we do into a process. It sounds paradoxical, but it isn't: a good process also allows for the fact that not everything has to be squeezed into a process!

So in our day-to-day work, our proven maxim remains: once we've handled a new task, we ask ourselves whether the path to the solution was a one-off, or whether we'll encounter it again in this form. And only if we answer that question with "yes" do we turn it into a process.