Skeptics of Security Brutalism usually bring up the same objection, that a philosophy built around fundamentals and disciplined restraint seems to have no room for audits, frameworks, and the paperwork that regulators demand. The objection misses what's actually being argued. Compliance requirements are real and often mandatory, and treating them as security theater doesn't make them optional, since a failed audit can shut down a business just as fast as a breach can. The point isn't to pretend compliance doesn't count, but rather to stop confusing it with security in the first place.

A control that satisfies an auditor and a control that improves an organization's ability to survive an attack are different things, even though both are worth pursuing and both deserve the effort. An access review that checks a box for SOC 2 might do nothing to stop a determined adversary who already has a foothold, and a segmentation project that meaningfully slows an attacker down might not map cleanly onto any framework a regulator recognizes. Running compliance and security as one track, under one set of priorities, is what leads teams to mistake the appearance of security for the practice of it. Running them as two separate tracks, each with its own goals and its own measures of success, is what lets an organization actually be good at both instead of struggling at whichever one has the louder deadline this quarter.

GRC deserves its own lane in this picture, running alongside the fundamentals rather than substituting for them. Plenty of controls end up serving both purposes at once, since a well-run identity program can satisfy an auditor and cut off a real attack path at the same time, and where that overlap exists, it's worth building on. The overlap isn't guaranteed, though, and assuming it exists everywhere is how organizations end up with a clean audit report and a network that falls over the moment someone determined actually tries it.