Infrastructure security

We start with access. We list every account with access to the servers, databases, the network and the cloud provider's console: who has it and why. We close the accounts of people who have left and accounts shared by several people, and from then on an employee's departure triggers a list of accounts to close.

For accounts with access to servers and data we turn on two-factor authentication: besides the password, the login has to be confirmed, for example with a code from a phone, so the password alone does not open the system.

We check backups by restoring them: we start the system from them on a separate server and measure how long it takes and what is missing. One copy is kept out of reach of administrator accounts, so that a mistake or an intrusion cannot delete it along with the data.

Updates are fixes from the makers of systems, databases and network devices; we record what needs them, who applies them and when. A system or device that its maker no longer supports is fenced off in the network until it is replaced. We encrypt data, meaning we store and transmit it in a form that cannot be read without a key, so that a lost disk or an intercepted connection does not reveal its contents.

We divide the network into segments: office computers, servers holding data, a guest network and devices without updates, and only documented, necessary traffic passes between them. Remote access goes through a single entry point with two-factor authentication.

Event monitoring is a record of what happens on the servers and in the network: who logged in, from where, what they changed, what stopped working. An event that needs a response, such as an administrator logging in at night from an unknown location, triggers an alert to a designated person in the company or to us, as the contract specifies; we do not run a 24-hour monitoring centre.

We run a disaster recovery test with your IT department: we simulate the loss of a server and start the system from backup in the documented order, timing it. An incident is an event in which an outsider has got into the system or data has left the company; for such a case we write down who decides, whom to notify, what to disconnect and what not to delete.

If your company falls under cybersecurity legislation, the Polish National Cybersecurity System Act (KSC) and NIS2, these technical measures enter the project for that reason too; the remaining requirements of that legislation are a separate service. A cloud design, installation in your server room and moving a system between environments are separate scopes; we do not carry out penetration tests, that is, controlled break-in attempts.

The result is a description of the security measures, an access register, and procedures for recovery after a failure and for handling an incident.

1. We check the current state. We examine the servers, network and accounts from the inside and talk to the IT department. Result: a review of the current state with a list of fixes ranked by risk, for your decision.
2. We put access and backups in order. We close unnecessary accounts, turn on two-factor authentication and do a trial restore of the system from backup. Result: an access register and a report on the first restore.
3. We secure the network and systems. We segment the network, turn on encryption, apply overdue updates and start event monitoring. Result: the environment in the target state set out in the review, with alerts tested in a trial run.
4. We rehearse and hand over. We run a disaster recovery test and go through the incident procedure with the IT department. Result: procedures corrected after the exercise and a schedule of further tests.

1. Who has administrator access to our servers and network today, and when was that list last checked?
2. When did someone last restore our system from backup, and how long did it take?
3. Will a backup survive the deletion of data by someone with full access to the servers?
4. Which of our systems and devices no longer receive fixes from their maker, and what will we do about them?
5. Who will receive an alert about an unusual login at night, and what should they do then?
6. Which security measures will our IT department maintain after the work is finished, and what does it need to learn for that?

Which areas need work in your company is shown by a review of servers, network and access; we start with that analysis and end it with a recommendation and a scope of work.