- Home
- How we work
How we work
We did not write these habits for the website: they come from our working notes, where they repeat project after project. They serve one purpose only: whoever entrusts us with their systems should always know what we are doing, on what evidence and with what way back.
The habits that do not change
-
Measure first, then state
Every conclusion rests on data: a log, a measurement, a test that can be repeated. When something is estimated or inferred, we write it next to the number. The load on a server is read from memory and CPU pressure, not from the load average; the free space on a volume is read on the volume, not in the console’s cache.
-
Read-only, until something else is needed
Investigations, checks, inventories and monitoring work read-only. A system is touched only when there is a reason and a plan, and commands that change something on a client’s devices are run exactly as agreed, with no unscheduled “tests”.
-
The way back before the change
Before changing anything in production we prepare the way back: a copy of the configuration, a scheduled automatic rollback that reopens access if a firewall change does not hold, the previous version of an application ready to be put back. Whoever works remotely must never lock themselves out.
-
A green dashboard is not enough
Many failures make no noise: an expired certificate that stops log collection, an antivirus installed but switched off, a backup that has been failing for weeks. That is why we check the real effect (the latest data received from each source, the service that answers, the protection that is on) and not just the traffic light.
-
Real data only
In the platforms we build, in tests and acceptance runs too, every number and every object on screen traces back to data downloaded from a real source. When something is modelled or inferred, such as the shape of an object in a 3D scene, we declare it and keep it separate from measurements. Missing data is shown as missing, never made up.
-
A minimal footprint towards the outside
What can be seen from the internet must be the bare minimum: no versions, no product names, generic errors, administration behind a VPN. This applies to this site too: static pages, no code running on the server, no resources loaded from other sites.
-
Everything in writing
Steps, decisions and measurements stay documented in the project file, not in a chat or in someone’s memory. Whoever comes next, the client included, must be able to understand what was done and why, and to redo it.
-
The client decides the release
We test first on one workstation or in a test environment, show the result and release when the client gives the go-ahead. This holds for a phone bar as much as for a web portal.
When there is an incident
The sequence we follow when responding to a cyber incident. The order matters: each step protects the next one.
-
Contain
Isolate the systems involved without destroying evidence: disconnect them from the network, do not switch off a machine that still holds what is needed in memory.
-
Preserve the evidence
Memory, snapshots, targeted collection, disk images only when needed; SHA-256 hashes and chain of custody, always working on copies.
-
Reconstruct
Timeline, point of entry, persistence, what was read or taken, separating what is proven from what is only claimed.
-
Scope the data
Categories and volumes of the data involved, special categories of data, the roles of controller and processor: the basis for deciding on notifications.
-
Notify
Drafts for the Italian Data Protection Authority, for ACN and CSIRT Italia where NIS2 applies, and for data subjects when the risk is high, with the deadlines worked out.
-
Restore and close
Clean-up, verified credential rotation, reduced exposure and the checks needed so that the same failure does not happen again.