Everyone in the technical security industry has to do it, everyone hates it – reporting. If you’re for example a penetration tester and you’ve identified a missing patch on a target, reporting is quite easy: “Patch X is missing on target Y but you should totally install it because of vulnerability Z”. Today our industry is facing way more complex situation, be it in incident response, attack forensics, red teaming or even threat modelling. When you’re trying to explain an attack to a client, this can be done by using a step by step approach but lets be honest, normally there’s not just one straight line from the attacker to the final target. Most often we find ourselves in a situation, where our work looks more like a rather complex graph that we traversed in multiple ways during an assignment. Unfortunately, a bunch of sequentially ordered papers is very bad for representing something that is really a graph and it’s therefore an insufficient deliverable to hand over to a client. So do we have to find a new form to deliver reports? Should we change our approach on analyzing and performing attacks so they can still be put on paper? Can visualization help us explaining what we’ve done and why? In this presentation I won’t be able to provide you with any answers for those questions. What I can do, is showing you some different ways of how my colleagues and I at Redguard have tried to approach those questions and what kind of dead-ends we hit. If everything goes well, I can share our pain with the audience and in the discussion groups we would then see what others tried and who knows, maybe together we find the magical unicorn of reporting formats.