Every company is going digital and must comply with a growing number of standards. An information system (IS) security audit has become a must.
What is an information system (IS) audit?
An IT audit is an in-depth review, by an independent expert, of a company’s architecture, processes and IT policies. Its main goal is to check the company’s compliance with security standards, regulations and internal policies, and to assess IT security risks (an information security audit).
Two types of audit:
- External audit: this can be voluntary, if your company wants an outside perspective or lacks the skills in-house. The firm carrying it out must be independent. It can also be mandatory (an inspection by the CNIL, the French data protection authority, a condition for fundraising, etc.).
- Internal audit: carried out by the company’s own employees, often on a recurring basis. The aim is to identify opportunities to improve and optimise IT systems. Repeating it makes it possible to apply the Deming wheel, or PDCA cycle (Plan Do Check Act), which is essential for change management.
The purpose of an internal audit is to improve the IS regularly, so you’re ready for external audits, which provide an impartial view.
Here are a few examples of what to review during an audit:
- Network configuration
- Architecture
- Database technologies
- Backup policy
What is an information system security audit?
An information security audit assesses vulnerabilities, threats and risks to data security, based on an understanding of business processes. It also assesses compliance with the standards and regulations that apply to the company.
Here are a few things to check during this audit:
- Penetration testing (with tools such as Exegol)
- Existence and review of the ISSP (Information Systems Security Policy)
- Compliance with the ANSSI IT hygiene guide
- User and access management
- Cryptography, password manager
IS audit vs information system security audit
The two audits described above are closely linked: a detailed IS audit includes the security audit, or at least part of it. In the earlier example, network configuration could fall under the security audit.
Carrying out an information system security audit, step by step
From here on, let’s assume we’re an independent firm hired to audit the IS of a company that wants to raise its level of IT security. Our job is therefore not just to carry out the audit, but also to support the company in implementing the improvements.
Preparation
Before starting the audit, you need to define the scope and set the objectives.
You must obtain the necessary authorisations and inform the parties involved (e.g. if you plan to run a penetration test on infrastructure hosted by a provider such as OVH).
During preparation, ask yourself several questions: which parts of the IS should be examined? Who will read the report? What are the deadlines? What deliverables are expected? And above all, how much time is allotted to the audit?
PS: when carrying out an audit, it’s wise to qualify your findings with “within the allotted time”.
Gathering requirements
Requirements gathering is also called the interview phase. Its purpose is to question the various stakeholders to gather as much information as possible about the IS, in order to understand the context, the company’s missions and the key processes that keep it running.
Example: for a hosting company, backups and availability will probably be key processes.
Here are some typical interview questions:
- What are the information system’s operational objectives?
- What critical processes and activities depend on the information system?
- What is the company’s information management policy, and how is it enforced?
- Who is responsible for what?
- What technologies are used to manage the information system?
- Is sensitive data protected and managed?
- Are security incidents handled and logged?
- Is the code under version control?
In this phase, collect as many existing documents as possible: IT usage policy, previous internal and external audits, BCP and DRP, or SLAs in our hosting example.
Some documents are essential; if they don’t exist, they’ll need to be produced before or while implementing the recommendations:
IS master plan
The IS master plan defines how the information system will evolve to support the company’s future missions while remaining aligned with its current ones.
A few things to consider when writing a master plan:
- Define the company’s current missions
- Define future missions
- Define internal and external constraints
- Organisational structure
- And so on.
IS business plan
The IS business plan, closely tied to the master plan, defines the strategies and objectives the current information system must meet. It specifies which resource meets which need(s), along with the associated costs and responsibilities.
Its main purpose is to ensure the information system is aligned with the company’s objectives and meets business needs.
Business Continuity Plan (BCP)
The BCP describes the measures needed to keep a company’s critical activities running. On the IT side, it’s also called an IT Continuity Plan.
An article on BCPs and IT continuity plans is in the works.
Disaster Recovery Plan (DRP)
The DRP describes the measures needed to restart a company’s critical activities. On the IT side, it’s also called an IT Recovery Plan.
An article on DRPs and IT recovery plans is in the works.
Diagnosis
During the diagnosis phase, you analyse all the data gathered so far to identify the company’s strengths and weaknesses. This step is just as crucial, because it lets you build the IS strategy and draw up a relevant action plan.
This step may reveal grey areas. It’s common to ask for clarification and go back to requirements gathering. Together with writing the report, diagnosis is the most time-consuming phase.
In our example, the audit isn’t an end in itself, but a necessary step towards the actual goal: raising the company’s level of security.
Writing the report
The report should be formal and as comprehensive as possible. Since it contains the findings and recommendations, it will serve as a baseline to measure progress over time.
The action plan can be added to the report, or put in a separate document after the presentation.
Presenting the report
The presentation is very close to the report, although we recommend using a different format so it’s easier to digest.
It covers the identification of improvement projects, the IS strategy and the action plan to achieve the company’s objectives. This part will probably change, as companies don’t always agree with the time estimates or priorities, which is normal since they have a broader view than the auditor. A discussion phase follows, with both parties making their case, to reach an action plan aligned with the objectives.
Defining the action plan
The action plan includes the measures from the report that the company approved after the discussion phase.
It covers the measures needed to meet the initial need, as well as the vulnerabilities, weaknesses or problems found along the way.
It includes priorities, deadlines and effort estimates (often in person-days), the people responsible and the resources needed to fix the problems.
Estimating the cost of the action plan
The cost depends on the number of person-days, the skills required and the impact on the company.
Running the IS improvement plan
In our case, the company wants us to take charge of the action plan, which becomes our improvement plan. We’ll be responsible for deadlines, improvements and fixes.
We recommend agile methods or, at the very least, tools such as Trello, Microsoft Project, YouTrack or even Excel. Progress dashboards can be built with Tableau or Power BI.
Evaluating the action plan’s implementation
In keeping with PDCA and continuous improvement, regularly evaluate how the action plan is being implemented, so you can course-correct as early as possible.
The benefit is twofold: it keeps the company and stakeholders informed of progress, and lets you get back on track if deadlines slip.
Leave a Reply