Terms that are easy to confuse
Most confusion about compliance tooling comes from using these words interchangeably. They mean different things:
- Requirement: what a framework, law or contract says must be true, for example that access to systems is limited to the people who need it.
- Control: the safeguard an organisation runs to meet a requirement, for example key-only SSH, a quarterly access review, or applying security patches within a set time.
- Evidence: a record that shows a control existed and operated, with a date and a scope. A configuration export, a log extract, a change ticket, a signed review.
- Assessment: an evaluation of whether controls are implemented and working, internal or external. NIST describes three methods: examining documents and records, interviewing people, and testing mechanisms.
- Audit: an independent, formal examination of evidence against defined criteria, which ends in findings or an opinion.
- Attestation: a formal statement by an accountable party that something is true, such as the attestation of compliance a PCI DSS assessment produces, or management's assertion about its internal controls.
- Certification: a formal statement by an accredited body that an organisation, system or product meets a standard, for a stated scope and period. Not every framework offers one; some are obligations you demonstrate when asked.
What counts as technical evidence on a Linux server
A server can produce a good deal of evidence about its own state, provided something collects it consistently and keeps the dates:
- Configuration state: the effective SSH settings, firewall rules, password and lockout policy, enabled services, time synchronisation.
- Access: the accounts, sudo grants, privileged group members and authorised SSH keys at a point in time, and the history of changes to them. The review of that list (who looked, when, and what they decided) is a separate, human record.
- File integrity records: hashes of critical files and a log of what changed and when.
- Vulnerability and patch records: installed packages matched against advisories, and the update history that shows when fixes were applied.
- Authentication and incident logs: logins, failures, alerts raised, and what was done about each.
- Backups: that jobs ran and, more importantly, that a restore was tested. The restore test itself is usually a person's exercise with its own record.
What software cannot evidence
A large part of every framework is about people and process, and no agent on a server can see it. Physical security of the data centre or office, written policies and their approval, staff training, background checks, vendor and supplier management, risk assessments, business continuity planning and data classification all need documents, sign-offs and interviews.
Some technical items sit outside the host as well: multi-factor authentication configured in an identity provider, encryption on a storage array, network segmentation enforced by switches or cloud security groups. A tool that marks those as covered from inside one server is overstating what it knows.
Automated and manual evidence
Automated evidence is generated by a system on a schedule or on change. It is consistent, timestamped and hard to stage for an audit day. Its weakness is scope: it covers only what the system was set up to watch, and a gap in collection looks like a quiet period unless the tool reports its own gaps.
Manual evidence (screenshots, exported reports, meeting minutes, signed reviews) is flexible and often the only option for process controls, but it is a snapshot. A screenshot proves a setting on the day it was taken, not across the months an assessor asks about.
Most programmes need both. Continuous monitoring, as NIST describes it, turns as much of the technical half as possible into automated evidence, leaving people the half that needs judgement.
Freshness and retention
Evidence has a date, and the date matters. An assessor usually asks whether a control operated throughout a period, not whether it is in place today, so evidence gathered in the week before an audit answers the wrong question.
How long to keep it is set by each framework and by your own policy, and the periods differ, so check the text that applies to you. Keep logs and reports somewhere the systems they describe cannot alter: evidence an intruder could have edited is weak evidence.
Why evidence is not compliance
Compliance is a judgement about an organisation, for a defined scope, against a specific framework, made by someone with the standing to make it: a qualified assessor, an external auditor or a regulator. Evidence is what they look at. Good evidence makes that judgement quicker and better founded; it does not make it.
That is why a tool is never a certification. A dashboard with every check passing describes the checks the tool ran, on the systems it could see, on that day, and nothing about the policies, people and systems outside its view.
Which frameworks apply depends on the organisation: its sector, its location, the data it handles and its contracts. Frameworks that ask for this kind of server evidence include UAE IA (formerly NESA), the UAE Personal Data Protection Law (PDPL), PCI DSS 4.0.1 for systems that handle card data, and SOX IT general controls for companies subject to SOX. This page is not legal advice; your counsel, assessor or regulator decides what applies to you and whether your evidence meets it.
UAE IA (NESA) on Linux serversPCI DSS 4.0.1 on Linux servers
Where SecAI fits
SecAI produces compliance evidence reports for UAE IA, PDPL, PCI DSS and SOX ITGC programmes from what its agent observes on each server: SSH configuration and posture, authentication events, accounts and sudo grants, changes to the files that grant access, installed packages matched against CVE data, and the incident history it keeps. The compliance page shows how those observations map to controls and which controls remain manual work.
It is evidence, not certification. SecAI does not make an organisation compliant by itself, and the judgement stays with your assessor.