A political website hacked: when *integrity* matters more than confidentiality

What happened

On Saturday, visitors to vansterpartiet.se didn't see the party's policies or the party leader's face. Instead, they got redirected to adverts for an Indonesian online casino and something called dobbel ^[1].

That's a defacement: someone changed what was on the site without the site's owner agreeing to it. It's also what the GDPR calls a breach of integrity. Most people think of data breaches as leaks—secrets getting out. But changing what's on a system is just as much a breach, and sometimes more damaging, because it breaks trust in what you thought you could rely on.

Political parties hold member lists, donation records and email addresses. If someone can change the website, the question is what else they could change, and whether anyone would notice before it mattered.

Why defacements matter

Integrity is one of the three things the GDPR tells you to protect, alongside confidentiality and availability ^[2]. It means keeping things unchanged unless the change is authorised. A website defacement usually hits integrity and availability at once: the site shows the wrong content and can't serve the real content.

In some sectors, a breach of integrity is worse than a leak. Think of a bank's transaction log: if someone can silently change the record of a payment, the damage isn't that they saw the payment; it's that you can no longer trust the log.

That's why access logs, audit trails and version histories exist. But here's the catch: those records are kept by the same people who could change them. It's like keeping a receipt in a drawer where anyone with a key can rewrite it. It works until someone questions whether the receipt you're showing is the one you wrote on the day.

The reporting duty under the Cybersecurity Act

From 15 January 2026, the Cybersecurity Act applies in Sweden. It implements the EU's NIS2 Directive and covers essential and important entities in 18 sectors, including public administration and digital infrastructure ^[3].

Political parties processing personal data are included as important entities. When an incident has a significant impact on the continuity of the service, the entity must send an early warning within 24 hours of becoming aware of it, an incident notification within 72 hours, and a final report within a month.

A website defacement that redirects users and prevents the site from serving its real content is likely to count as significant. That starts the 24-hour clock, not from when the hack happened, but from when someone at the organisation knew about it.

The duty is to report what you know, as soon as you know it. The hard part comes afterwards, when an auditor or a supervisor asks what happened, when you first detected it, and whether the logs showing the timeline have been touched since.

The integrity problem with logs

Logs tell the story of an incident. They show who accessed what, when a system was changed, when an alert fired, and when someone escalated it. But logs are stored on systems controlled by the same people who are reporting the incident.

If a log can be edited after the fact, a regulator or an auditor can argue that it might have been. That doubt doesn't mean the log was changed; it means nobody can prove it wasn't. In a dispute, that's often enough to question the timeline.

Access controls and monitoring are the foundation. Role-based permissions, multi-factor authentication and segregation of duties make it harder for one person to change a log quietly. But they don't make it impossible, and they don't give you a simple way of proving to someone else that a log is unchanged.

That's where integrity controls designed for proving, not just protecting, come in.

What a digital witness does in incident handling

Here, the thing to seal is each detection note, escalation decision and report as it is recorded. Sealing takes a fingerprint of the record—not the record itself—and anchors it in a way that any later change, even by someone with administrator rights, would show up.

The fingerprint is sent to WitniumChain through the REST API, the SDK or the MCP server, and you get a witness ID back. To check, anyone you share the record with calculates the fingerprint again and compares it with the sealed one. If it matches, the record is exactly what was sealed. Change one character and it won't match.

That gives you a way of showing a supervisor or an auditor that the timeline you're presenting is the timeline you recorded at the time, not a version written with hindsight.

The content of the logs never leaves your systems. What gets sealed is a mathematical summary of the content, a couple of hundred characters long, that changes completely if anything in the log changes. It's less "here is a copy" and more "here is a way you can check this yourselves".

What it doesn't do is replace access controls, monitoring, backups or the logging itself. It also doesn't prove that the log is complete, or that the response was adequate. But it does answer one narrow question that tends to come up when an incident is reviewed: "Can we trust that this is what you wrote on the day?"

How it would work

1. Log segments are sealed at short intervals, such as every few minutes, as each segment closes.
2. Key events—first detection, escalation, each report sent—are sealed individually as they are recorded.
3. When a supervisor or auditor later reviews the incident, they can check each sealed record and see that it hasn't been touched since it was created.

The first 2,000 witnesses a month are free. Getting started takes a few lines of code.

What this means for you

If your organisation is covered by the Cybersecurity Act—or if you handle personal data and need to be able to show GDPR compliance after an incident—ask these three questions now:

• Who keeps the logs, and who can change them?
• If someone questioned a log entry six months after an incident, could you prove it's unchanged?
• Do your incident response procedures say when to seal a record, and who does it?

Incident reporting is about showing what you knew and when. The story you tell has to hold up long after the incident is over, and logs are what make the story checkable.

What to watch

The Cybersecurity Act applies from 15 January 2026. The Authority for Privacy Protection (IMY) supervises compliance for most entities, and the Swedish Civil Contingencies Agency (MSB) supervises certain critical sectors. Early warnings are due within 24 hours of becoming aware of a significant incident.

The Digital Operational Resilience Act (DORA), which has applied to financial entities since January 2025, requires ICT logs to be protected against tampering, deletion and unauthorised access ^[4]. That's a model other sectors are likely to follow.