If you’re on Armor Business, a quarterly configuration review is part of what you’re paying for — but if it’s never been explained beyond the name, it can be easy to treat as a formality rather than something genuinely worth your attention. Here’s what actually happens during one, and why it exists as a recurring item rather than a one-time setup task.
Why This Isn’t a “Set It Once” Situation
Security configuration isn’t static, even if nothing about your site has visibly changed. Traffic patterns shift, new plugins get added, payment flows get updated, and the broader threat landscape evolves — new attack patterns emerge that older rule sets weren’t built to catch. A configuration that was correctly tuned six months ago can quietly become outdated without any single dramatic event causing it — just gradual drift between what’s configured and what your site now actually needs.
Step 1: Reviewing What’s Changed Since Last Time
The review starts by looking at what’s actually different about your site since the last check-in — new plugins installed, changes to your checkout flow, new subdomains added, traffic pattern shifts. This matters because new additions (a new payment gateway plugin, a new customer account feature) can introduce endpoints or behavior that existing WAF rules weren’t specifically built to cover.
Step 2: Checking for Configuration Drift
This looks at whether the actual current settings still match what was intended — has SSL mode stayed on Full (Strict), or did a server change accidentally revert it? Are all subdomains still properly routed through the proxy, or has a new one been added outside that protection without anyone noticing? Small, unintentional drifts like these are exactly the kind of gap that doesn’t announce itself until something goes wrong.
Step 3: Reviewing the Last Quarter’s Blocked Threat Patterns
Similar to the monthly report but at a broader scale — looking at three months of data to catch slower-moving patterns that might not stand out in any single month. A gradually increasing rate of a specific attack type, for instance, might not look alarming month to month but becomes clearer as a trend across a full quarter.
Step 4: Custom Rule Relevance Check
Custom WAF rules built for your specific application get reviewed for whether they’re still relevant — a rule built around an old plugin you’ve since removed is dead weight that should be cleaned up, while a new feature you’ve added might need a new custom rule that didn’t exist when the original configuration was built.
Step 5: PCI DSS-Relevant Configuration Check
For businesses where PCI DSS-ready configuration matters, this step specifically reviews whether that configuration still holds — TLS enforcement, access controls, logging setup — since PCI DSS itself isn’t a “pass once” standard; it expects this kind of ongoing verification as systems change.
Step 6: Recommendations for the Next Quarter
The review closes with specific, actionable recommendations rather than a generic “everything looks fine” — if something’s worth changing, adding, or removing, this is where it’s flagged clearly, in plain language rather than a raw technical audit dump.
What You’ll Actually Receive
A written summary covering what was reviewed, what (if anything) was found, and what’s recommended going forward — similar in spirit to a post-incident summary, but proactive rather than reactive: this is what’s changed and what’s recommended, not what went wrong and what was fixed.
Why This Matters More Than It Might Seem
The value of a quarterly review isn’t in catching some dramatic ongoing breach — it’s in catching the slow, unglamorous drift that eventually becomes a real gap if left unchecked: an SSL mode quietly reverted, a new subdomain nobody thought to route through the proxy, a custom rule that’s stopped being relevant. None of these individually looks urgent, which is exactly why they need a scheduled, deliberate check rather than waiting for someone to notice by accident.
| Review Step | What It Catches |
|---|---|
| Changes since last review | New features/plugins needing new rules |
| Configuration drift | Settings that silently reverted or weakened |
| Quarterly threat patterns | Slow-building trends invisible month to month |
| Custom rule relevance | Outdated rules to remove, new gaps to cover |
| PCI configuration check | Compliance-relevant settings still holding |
| Recommendations | Specific next steps, in plain language |
