Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Most websites host tracking systems that change continuously, tag by tag, pixel by pixel, version to version, often without anyone in privacy touching a line of code. Marketing adds a session replay script through the tag manager. Vendors quietly push updates to the tags. By the time it’s noticed in the next periodic review, the damage is done. Drift in tag behaviour leads to consent violations. And tracking scripts load and process data despite GCP signals.

So your team just uncovered a GDPR tracking violation, a consent anomaly that, after a deeper look, turns out to be a pixel firing regardless of consent state.” From the looks of it, it’s definitely an ePrivacy violation. But the harder question, the one you now have to race against time to answer, is whether this is also a notifiable breach under GDPR. For that determination, you now have 72 hours. One gets fixed with a tag manager update and a stern email to marketing.

U.S. state privacy compliance now operates in an environment that doesn’t stand still. The number of state laws keeps growing, and their requirements continue to evolve through new effective dates, amendments, and guidance. By January 2026 alone, Indiana, Kentucky, and Rhode Island added three more state privacy laws. This makes one thing clear. Compliance is no longer something you implement once and revisit periodically. It has to stay accurate as the requirements keep shifting.

The skimmer doesn’t go inside the iframe. It doesn’t need to. In every significant payment page compromise of the last decade, the malicious code sat on the merchant’s page, outside the payment component entirely, watching form submissions, intercepting keystrokes, reading values before they ever reached the provider’s sandbox. This is the architecture SAQ A-EP merchants live in.

Marketing needs to ship campaigns in hours. IT and engineering move in days. Tag managers live at the center of that conflict. They’re essential infrastructure, enabling marketing velocity by letting marketing teams deploy analytics, advertising pixels, and conversion tracking without IT or production bottlenecks. So campaigns launch faster, testing happens in real time, and teams optimize performance mid-campaign. But that same architecture can create compliance exposure.

If you have a consent banner, a Do Not Sell link, and a preferences database logging every opt-out, you’re CCPA compliant, right? Not really. In July 2025, Healthline Media settled with the California Attorney General for $1.55 million. That’s one of the largest CCPA fines to date. They had opt-out forms. They had GPC support. They had a preference database. Yet, after users exercised all three, investigators found that 118 cookies were still active and 82 tracking tags were still operating.

We’re excited to share that Feroot has been named one of G2’s Best Software Products of the Year for 2026 in the Data Privacy category. This recognition is especially meaningful because it’s based on direct customer feedback. G2’s awards are powered by real-world reviews and outcomes, and we’re honored that customers chose to share their experience with Feroot. Even more humbling: our customers have given us an average rating of 4.9 out of 5 stars.

Conversations about GA4 in healthcare tend to stay strangely shallow, circling the same procurement question: “Is there a BAA?” It’s as if GA4 creates risk at the contract layer, when the truth is that the risk is born earlier and lower, in the collection layer, where ordinary telemetry becomes sensitive the moment it is attached to health context and allowed to leave your site.

While the objective of protecting personal data is to be lauded, the current setup in the US is one of the most complex in the world. Twenty states. Twenty different thresholds and definitions. ‘Sale’ means one thing in California, another in Virginia. Tracking 275 daily website visitors puts you in scope for CCPA/CPRA, but not Tennessee’s law. 274 keeps you out of both. Just determining if a law even applies has become a legitimate challenge for businesses.

Ask five compliance leads in the gaming industry how 6.4.3 applies to their payment flows, and you’ll get five different answers. Ever since PCI v4.0.1 has come into effect, gaming and iGaming operators have been struggling to identify where they fall in scope, which SAQ paths apply to their specific architecture, and if Requirement 6.4.3 and 11.6.1 apply to them or their payment processors.

Nearly 70% of online purchases now happen on mobile, yet PCI scoping decisions are still often made as if mobile is just a smaller browser. It is not. A native in-app payment flow and a mobile web checkout trigger materially different obligations under PCI DSS 4.0.1. In one case, risk concentrates inside the application runtime through SDKs, platform storage, and release controls.

Very few people know this, but passing a PCI audit has very little to do with having defensible evidence. Your processor passed its last PCI assessment. Three months later, a merchant using your payment forms gets hit with a Magecart attack. Card brands start asking: What monitoring did you have on that checkout page? When did you detect the compromise? What evidence can you provide? That’s when the gap becomes obvious.