Security event logging
We set up security event logging: logins and failed attempts, administrator actions, permission changes, suspicious requests. So that you can see what happened, notice anomalies and investigate an incident. Honestly upfront: logs are VISIBILITY and material for investigation, not protection by themselves: they do not prevent an attack, they help notice and analyze it AFTER — and they only work if someone looks at them or alerts are set up.
Security event logging — overview
Security event logging is the setup of recording security-relevant events and storing them in a form convenient for analysis: successful and failed logins, lockouts, administrator actions and permission changes, suspicious requests and protection triggers, key data operations. We set up the format, the set of fields, rotation and retention period, and, if needed, basic alerts about critical events. Honestly about the role, this is key: logging is VISIBILITY and forensics (the ability to reconstruct the picture), NOT protection: a log by itself does not stop an attack and does not fix a vulnerability. Its value is to notice an anomaly and investigate an incident. Honestly about the condition for usefulness: for PROACTIVE response, logs that no one looks at are almost useless — you need to either review them regularly or set up alerts/monitoring (full monitoring/SIEM is a separate service). To be honest: even unwatched logs are useful for investigation AFTER an incident (forensics) — but without oversight they will not help stop an attack in time. We can do basic alerts for critical things. Honestly about privacy and law: passwords and excess personal data should NOT get into logs — we set this up carefully; storage of personal data is regulated (152-FZ) — that is a lawyer's area, we observe reasonable hygiene. Honestly about pre-existing data: our setup will not write passwords/excess personal data, but in ALREADY existing logs and backups such data may remain from previous settings (minimization is not always absolute) — cleaning it is a separate task. Honestly about storage: logs take space, a balance of retention period and volume is needed (storage costs are yours). Honestly about completeness: we log what is defined as relevant, but logging 'everything in the world' is unnecessary and harmful. Honestly about access: access to the server/application is needed. Honestly about the platform: on some shared hosting and SaaS CMS, logging is managed by the provider and custom detailed logging may be impossible — we check in advance whether it is feasible for you, and if not, we will say so honestly. An important boundary: this is logging (visibility), while 24/7 reaction/monitoring and WAF/protections are separate measures. Picture this: instead of 'it is unclear who did what and whether there was an incident' — there is a transparent journal showing a login, an action, an anomaly. The base price starts from 12,000 ₽ per project; it depends on the number of events and the infrastructure.
Problems we solve
- After an incident it is unclear who did what — no traces.
- Failed logins and brute-forcing are not recorded.
- Administrator actions and permission changes are not tracked.
- Logs exist, but they are a mess, no rotation and no one looks at them.
What's included in the Security event logging service
- Defining security-relevant events to record
- Setting up the format, field set and log rotation
- Setting up the retention period (volume/usefulness balance)
- Basic alerts about critical events (optional)
- Privacy hygiene (not logging passwords/excess personal data)
- Indicating boundaries (logs — visibility, not protection)
- Verification on real events
- Handover and review with you
What you get
- A transparent journal of logins, actions and anomalies
- The ability to investigate an incident after the fact
- Logs structured, with rotation and a retention period
- Visibility (reaction/24-7 monitoring — separate)
How the work goes: steps
- We define relevant events and requirements; collect access
- We set up recording, rotation, privacy hygiene, basic alerts
- We verify on real events, review boundaries with you
Why PDV Expert
- Fixed price and timeline — no surprises on the invoice.
- Report and recommendations in plain language — clear without a technical background.
- In touch at every step and answering questions about the result.
FAQ
Will logging protect the site from being hacked?
No, this is not protection but visibility. A log does not stop an attack and does not fix a vulnerability — it helps notice an anomaly and investigate an incident afterward. It is a critically important layer (without logs you are blind), but it works together with real protections, not instead of them.
Will the logs be really useful?
For a timely reaction — only if someone looks at them or alerts are set up: unwatched logs barely help stop an attack in time. But honestly: even they can be used for investigation AFTER an incident (forensics). So we can set up basic alerts for critical events; and if constant oversight is needed — that is monitoring/SIEM (a separate service). We will honestly say what you really need.
Is personal data in logs legal?
Passwords and excess personal data should not get into logs — we set up recording carefully. The storage of personal data itself is regulated (152-FZ), and the legal side is a lawyer's area; we are responsible for technical hygiene: what we log and how we store it.
About the provider
The «Security event logging» service is provided by PDV Expert — a team specialising in «Site quality». We work under contract and deliver a written report with recommendations.