Security and technical assessments

What we do

1. 01

   Technical review

   We look at how the systems really are, not only at the documentation, and rank the findings by risk and effort. The output is a report and a concise plan: what to fix now, what later and what to accept as a risk. We review:

   • accounts, permissions and access, including suppliers and service accounts
   • the network and the services exposed to the internet
   • the patch level of systems and applications, and known vulnerabilities
   • logging, monitoring and alerting
   • backups and the recovery plan
   • cloud configuration: permissions (IAM), publicly accessible storage, encryption
   • development and delivery: CI/CD, secrets, dependencies and their vulnerabilities
2. 02

   Identity and access

   Who can get where, and with which rights. The goal: every access has a name and a reason and can be removed quickly. We put in place:

   • personal accounts instead of shared ones, and single sign-on (SSO) where systems support it
   • multi-factor authentication (MFA), mandatory for administrators, e-mail and remote access
   • least-privilege permissions and separate administrator accounts
   • privileged access only for as long as needed, with a record of what was done
   • a joiner and leaver process for people and suppliers: access is granted and removed by process
   • regular reviews of who has which access, and removal of unused accounts
   • passwords and keys in a password manager or vault, not in documents and e-mails
3. 03

   Network

   So that only what should be visible from outside is, and a problem in one part doesn’t spread to the others. We put in place:

   • an inventory of everything reachable from the internet, and closing what doesn’t need to be
   • network zones (for example production, management, office, guests) and rules between them
   • remote access through a VPN or zero-trust access, not through open ports
   • encrypted communication (TLS), also between internal services
   • protection for web services (WAF, rate limiting) where it makes sense
4. 04

   Logging and detection

   Without records an incident can be neither spotted in time nor investigated afterwards. We put in place:

   • central collection of sign-in, administrative-change and security-event logs
   • alerts on suspicious events, such as unusual sign-ins or permission changes
   • log retention for an agreed period, protected against deletion
   • an incident procedure: who does what, whom to inform and how to report it if NIS2 applies to you
5. 05

   Backups and recovery

   A backup is proven only by a test restore. We put in place:

   • backups kept apart from production and protected against overwriting and deletion
   • a copy outside the main environment, for example with another provider
   • regular test restores of a whole service, not just a single file
   • a known recovery time and maximum data loss (RTO, RPO), agreed with management
6. 06

   Remediation

   Following the priorities, we put the controls in place in your infrastructure and development processes and verify each one, for example with a test restore or an access review. We design them so they don’t get in the way of everyday work. Typically:

   • patches and updates by priority
   • removing stale accounts and former suppliers’ access
   • secure configuration of systems and cloud (hardening)
   • encryption of data in transit and at rest
7. 07

   Evidence for audits and NIS2

   Technical evidence that the controls work. It serves an audit, ISO 27001 and the obligations under NIS2. It contains:

   • an overview of the controls in place and how each is proven
   • who is responsible for what
   • records of test restores, access reviews and updates
   • ongoing checks so the evidence doesn’t go out of date