Compliance and Audit Readiness

Secure is not the same as compliant

A server compliance audit is the exercise of proving, with evidence, that the server you secured is actually secure. This chapter turns the hardening from the last four chapters into logs, configs, and records you can hand to a customer's security team or a regulator.

You can run the most hardened server in the country and still fail an audit.

Because being secure and being able to prove you are secure are two different things. Security is the state of your server. Compliance is the evidence you can produce when a customer's security team, a regulator, or an incident investigation asks: who had access, what was logged, how long do you keep it, and can you show me?

Most technical people are good at the first and neglect the second, right up until a big customer's procurement form asks for it, and there is nothing to hand over. This chapter is about turning the work from the last four chapters into something you can demonstrate.

Prerequisites

Measure yourself against a standard, and get a number

You cannot manage what you do not measure. Instead of a vague feeling that the server is "pretty secure," score it against a recognised benchmark. On Ubuntu 24.04, lynis, from the first chapter, does exactly this:

sudo lynis audit system

At the end it gives you a hardening index and a list of specific, prioritised findings:

That number is the point. On our test server it reads 64, with 1 warning and 51 suggestions, each one a concrete, named thing to fix. It is not a grade to be ashamed of or proud of; it is a baseline you can track. Run it monthly, watch the number climb as you work through the list, and you have turned "are we secure?" into a metric with a trend, which is exactly what an auditor, or your own future self, wants to see.

The CIS Benchmarks are the heavier, more formal version of the same idea: a detailed, consensus checklist for how a given system should be configured. Many compliance frameworks map directly to them. Lynis is where you start; CIS is where you go when a customer contract demands it.

Work the list down, do not just admire it

A score is only useful if you act on it. Lynis does not just give you a number, it gives you a list of specific findings, each with an ID you can look up:

sudo lynis show details TEST-ID

The discipline is simple. Read the suggestions, pick the handful that matter most for your setup, fix them, and run the audit again. The number moves. That movement, from 64 to 71 to 78 over a few sessions, is the single most convincing thing you can show: not a static claim of "we are secure," but evidence that you measure, act, and improve. An auditor trusts a rising number with a history far more than a one-time perfect score with none.

Resist the urge to chase 100. Some findings will not apply to your workload, and forcing them can break things. The goal is a defensible, improving posture where every gap left open is a gap you understood and chose, not one you never saw.

What does India actually require?

If you host in India, or serve Indian users, two things set real, specific obligations, and both are core to how ServerCake is built.

The CERT-In directions require, among other things, that you keep system logs for 180 days, hold them within India, and report certain security incidents within 6 hours of noticing them. The logging and auditd work from the last chapter is not just good practice here, it is how you meet a legal retention requirement. A server with no logs, or logs that rotate away after a week, cannot comply.

The DPDP Act (Digital Personal Data Protection Act) governs personal data: lawful processing, honouring data-principal rights, and notifying the authority and affected people after a breach. You cannot notify accurately about a breach you never detected, which is why the detection chapter and this one are the same story told from two directions.

You do not need to be a lawyer to start. You need logs that are retained, access that is controlled and recorded, data that stays where it should, and a written note of who is responsible. That is most of the way there.

A server compliance audit is documentation, not vibes

Here is the shift that trips people up. An auditor does not care how confident you feel. They care what you can show. For every claim, there has to be evidence:

• "Access is controlled" becomes: a list of who has accounts, on what, with which privileges, and a record of changes (your scoped roles and auditd log).
• "We keep logs" becomes: a retention setting an auditor can read, showing logs held for the required period.
• "Data is encrypted" becomes: the actual TLS and at-rest encryption config, not an assurance.
• "We would know about a breach" becomes: the monitoring and alerting, and ideally a written incident-response plan (the next chapter).

The pattern is the same every time: a claim, backed by a config or a log you can point at. Compliance is the discipline of making your security legible to someone who was not there when you set it up.

The folder you want to already have

When a serious customer's security team sends their questionnaire, or an auditor books a call, the difference between a calm afternoon and a scramble is whether the evidence already exists. Build it once, keep it current, and the answers write themselves. A minimal, genuinely useful set:

• An access list. Who has server and database accounts, at what privilege, and a note of the last time you reviewed it. Your scoped roles and auditd log are the raw material.
• Your hardening baseline. The latest lynis or CIS report, dated, plus the trend. It shows both where you stand and that you track it.
• Retention proof. The journald and database log settings that show you keep records for the required period.
• Encryption proof. The TLS and at-rest configuration, so "we encrypt data" is a config you can show, not a promise.
• An incident-response plan. A short written document of what you do when something goes wrong (the subject of the next chapter). Auditors specifically ask for this, and most people do not have it.

None of these is long. Together they turn every "how do you handle X?" into "here, look," which is the entire game. The work is not writing them once. It is keeping them true as people join and leave, configs change, and servers migrate.

The trap: passing the checklist, missing the point

The danger with compliance is the opposite of the danger with hardening. Hardening people forget to document. Compliance people forget to actually be secure.

A checklist can be gamed. You can tick every box, generate every document, pass the audit, and still be one unpatched service away from a breach, because a point-in-time checklist says nothing about tomorrow. Real compliance is not a certificate you earn once and frame. It is a posture you hold: the logs still retained next month, the access list still accurate after three people left, the encryption still on after the last migration.

This is where a one-time audit and a running business part ways, and it is exactly the work we built ServerCake to carry. Keeping the hardening current and the evidence current and the retention unbroken, month after month, so that the day a customer's security team sends the questionnaire, the answers already exist and are true, is not a project with an end date.

We designed our platform DPDP-aligned and CERT-In-aware from the start, not because a checklist demanded it, but because retrofitting compliance onto a system that was never built for it is the hardest work there is. The posture is the product. Holding it, so you can always prove it, is the part we do not hand back.

Key facts

• Being secure and being able to prove it are different. Compliance is the evidence, who had access, what was logged, how long it is kept.
• Score your server against a benchmark with lynis (hardening index plus prioritised findings) and track it over time. CIS Benchmarks are the formal version.
• CERT-In requires 180-day log retention, India-resident logs, and 6-hour incident reporting. The DPDP Act governs personal data and breach notification.
• Every compliance claim needs backing evidence: a config, a log, an access list, not an assurance.
• A checklist passed once is not compliance. The posture has to hold month after month, or the certificate is fiction.

Frequently asked questions