Audit and Compliance Preparation
The audit notice is on the table. 8 weeks. Now you find out what you can't actually prove.
In most organizations, compliance exists as intention: described in Word documents, held as tribal knowledge, practiced without evidence. Auditors ask differently. They ask for specific proof, timestamps, documented exceptions, and the process behind each control.
lennlay builds audit readiness structurally: defined baselines as versioned policy artifacts, automated compliance scans with structured reports, GitOps-based change history, and risk-based exception management. What the auditor wants to see is there.
What the auditor asks. What most teams can show.
The classic gap: compliance documented as intention, not as technical evidence. The following four questions are not edge cases. They are the standard.
"What hardening standard applies to your JBoss server?"
"We follow our internal guidelines."
Auditor: "Show me the evidence."
"Who changed which configuration, and when?"
"That should be in the ticketing system... somewhere."
"Are there deviations from the target state? Are they documented?"
"We have no known deviations."
Auditor: "How do you know that?"
"What is your process for a security incident?"
"We have a plan."
Auditor: "Where is the plan? Has it been tested?"
Four categories. Each with specific evidence requirements.
Hardening Evidence
Which standard? Which controls applied? Which version of the benchmark? Not "we have hardening" but: CIS L1, Policy ID 24.2, applied on 2025-03-15, 3 documented exceptions.
Change History
Every configuration change must be traceable. Who changed what, when, why, with what approval. Without Git-based configuration management, that means manual reconstruction under time pressure.
Exception Management
Every security exception needs documentation, a risk assessment, and an expiry date. "We decided not to apply this control" must be in writing, with a business justification and a validity period.
Drift Evidence
Has the system drifted from its defined state since the last audit? That requires continuous or periodic scanning, not a point-in-time check done the week before the review date.
Six building blocks for structural audit readiness
Defined Baselines
CIS Level 1 or Level 2 as a versioned policy artifact per platform: JBoss, Linux, Tomcat. Not a description, but a machine-readable policy with IDs, a date, and a defined scope.
Automated Compliance Scan
The lennlay Compliance Scanner runs against live instances and produces structured reports. No manual checklists, just structured output that internal revision and external auditors can use directly.
Change History via GitOps
Configuration as code, managed in Git. Every change is a commit with author, timestamp, and commit message. Rollback to any previous state is possible at any time.
Exception Documentation
Risk-based exception handling: exception ID, affected control, risk assessment, business justification, approval date, expiry date. Structured, traceable, and ready for audit.
Audit Report Export
Reports in auditor format: compliance status per control, documented deviations, exceptions with justification, remediation plan. Suitable for internal use and external reviews alike.
Drift Detection
Continuous or scheduled scanning compares the actual state against the baseline. Drift surfaces before the auditor finds it, not after.
Which regulatory frameworks lennlay addresses at platform level
| Framework | Audience | What lennlay addresses at platform level |
|---|---|---|
| NIS2 / NIS2UmsuCG | Critical infrastructure, regulated sectors | Article 21 technical measures: platform hardening, vulnerability management, logging, and evidence documentation |
| CIS Benchmarks | All sectors | Level 1 and Level 2 as an operational baseline per platform, with controlled, documented exceptions |
| BSI IT-Grundschutz | Public sector, critical infrastructure | SYS.1.1, SYS.2.2, APP.3: system hardening, configuration management, change documentation |
| ISO 27001 | All sectors | Annex A: technical security controls, access management, change management at platform level |
| DORA | Banks, financial services | Article 9 technical risk management: platform hardening, incident documentation, auditability |
| BaFin BAIT | Banks | IT hardening, change documentation, revision-safe evidence at platform level |
| PCI-DSS | Payment processing | TLS configuration, access control, change management, per-control hardening evidence |
The 8-week window is not when you start. It is when you validate.
Platform hardening and audit readiness need to be operational, not reactive. Structural auditability cannot be built in response to an audit notice.
The first external or internal audit is coming up. There is no established baseline, no documented exceptions, no structured change history. Those are three separate gaps that need to be closed at the same time.
The annual audit cycle feels like starting from scratch every time. Evidence is gathered ad hoc, gaps are bridged under pressure, the team runs overtime. Then the auditor leaves and the cycle resets.
The last audit identified gaps. A remediation plan is required, and the next review will expect evidence that the gaps have been closed. The pressure is now structural, not just a matter of timing.
Tell us about your audit situation. In 15 minutes we can identify the gaps and show what structural audit readiness looks like in your environment.
Assess audit readiness