Identity
We have MFA. Why that is not enough
Why MFA (multi-factor authentication) alone does not prove protection: phishing resistance, token replay, OAuth consent, device requirements and controlled verification.
Clear guides for organisations that need to understand a requirement, prepare evidence or turn a finding into a working improvement.
Research publications · About the author
Identity
Why MFA (multi-factor authentication) alone does not prove protection: phishing resistance, token replay, OAuth consent, device requirements and controlled verification.
Identity and incident response
A practical response sequence for a compromised Microsoft 365 account: access, sessions, application permissions, evidence and verified recovery.
Identity and access
An offboarding checklist covering Microsoft 365 sessions, external applications, shared credentials, devices and evidence of completed access removal.
Trust and evidence
Check SPF, DKIM and DMARC, understand alignment and p=none, and test email impersonation without disrupting legitimate senders.
Practical guide
Collect a failed message and identify the service that sent it before changing settings. Delivery problems can involve authentication, reputation, mailing practices or the recipient’s filtering. A passing technical check is useful evidence, but cannot guarantee inbox placement. Diagnose one sending path at a time and preserve a baseline for comparison.
Email trust and human decisions
A payment verification process for fraudulent invoices, changed bank details and compromised suppliers, even when email authentication passes.
Compliance
NIS2 (EU cybersecurity directive) in Bulgaria: scope, essential and important entities, sanctions, registration and practical evidence under the amended Cybersecurity Act.
Compliance
Which NIS2 obligations already apply in Bulgaria, which implementing acts are still pending and the recurring deadlines. Checked in the State Gazette.
Compliance
The fines for essential and important entities under Bulgaria’s NIS2 law, the personal fine for managers and what reduces the risk.
Compliance
When NIS2 applies to a small company, when size does not matter, and how the law reaches small suppliers through their customers.
Compliance
What a Bulgarian mayor must do under the NIS2 law: approve measures, complete training, name owners, report incidents — and the personal fine.
Practical guide
Start with the legal entity, its actual activity and its enterprise data. Then check the exceptions and national law. A customer asking about NIS2 creates a reason to investigate, but does not establish direct legal scope. The useful result is a documented decision and a list of unresolved facts.
Article · published 13 September 2026
Both deal with cybersecurity, resilience, incidents and suppliers. The practical difference is who they cover, how detailed the obligations are and which authority supervises them.
Compliance
DORA (EU Digital Operational Resilience Act) register of information: templates, LEI and EUID, service-to-function mapping, validation and reporting. Practical checks for financial entities.
DORA and practical evidence
A worked DORA register example: preserve the submitted version, trace broken references, correct the source and verify the next submission.
Compliance
A bank sent you a contract addendum full of security clauses. Which ones DORA Article 30 makes compulsory, which are negotiable, what they cost you.
Practical guide
A policy describes the intended way of working. Evidence shows what happened within a defined scope and period. A useful DORA review connects the requirement, owner, control, record and corrective action. Begin with one important service and follow that chain before collecting documents across the organisation.
Article · published 13 September 2026
Lex specialis is not a switch that turns NIS2 off. It resolves an overlap: where two valid rules govern the same entity and the same subject, the more specific rule displaces the general one only for that overlapping part.
Article · published 13 September 2026
DORA does not replace GDPR (General Data Protection Regulation) and is not lex specialis in relation to it. DORA focuses on the digital operational resilience of the financial entity; GDPR protects people and their personal data. When the same system, provider or incident engages both, both regimes must be assessed.
Article · published 13 September 2026
Threat-led penetration testing (TLPT) is DORA’s most advanced testing layer. It is not an annual penetration test, a vulnerability scan or a requirement for every financial entity.
Trust and evidence
What each block of a vendor security questionnaire is really testing, and how to answer honestly — including the gaps — with evidence and clear next steps.
Practical guide
Treat each substantive answer as a claim needing an owner, scope and supporting record. A reusable evidence file prevents contradictory answers and repeated collection work. It also helps sales and technical teams distinguish what exists today from an improvement that has only been planned.
Incidents
Ransomware in 2026 starts with a working login, exposed remote access or a supplier account. Five controls, ranked by what they break in the chain.
Practical guide
A completed backup job does not establish that a business service can be restored. Check whether the copies remain accessible after account compromise, whether the recovery environment is usable and whether dependencies are included. The decisive test is an agreed business operation completed safely with recoverable data.
Incidents
The NIS2 and DORA incident clocks start at awareness, not at containment. What awareness means, who classifies, and the decisions to write down first.
Practical guide
Agree in advance who may investigate, contain and restore access, under which conditions and with what record. Monitoring permission and authority to interrupt a service are different decisions. A response plan becomes usable when a deputy can apply it without inventing the approval process during the incident.
Artificial intelligence
A one-page AI use policy that holds: what may go in a prompt, which tools are approved, who checks output, and what the EU AI Act actually asks of you.
Practical guide
Define which tools may be used, what data may enter them and who checks the result before it affects a customer or business decision. Apply those rules to actual use cases. A short policy becomes useful when employees can recognise their task and know the approved way to complete it.
Artificial intelligence
Where machine learning and language models measurably help a security monitoring operation, where they hurt, and how to test a provider's AI claim.
Practical guide
Assess the path from a relevant attack scenario to a usable signal and an authorised response. A SIEM collects and analyses security events, but its presence does not establish coverage. Test what it can see, who investigates and what happens when the normal responder is unavailable.
Security monitoring and buying decisions
Evaluate MDR (managed detection and response) and SOC (security operations centre) proposals with agreed detection scenarios, response authority, evidence access, coverage limits and an acceptance scorecard.
Governance
CISO, vCISO (virtual chief information security officer) or combined IT/security role: compare authority, independence, availability and management accountability before choosing.
Leadership and buying decisions
Compare external CISO support by expert time, responsibilities, deliverables and availability. Published Dyasol prices and a practical buying worksheet.
Practical guide
A workaround is a signal to investigate both the behaviour and the work process. Ask what the employee was trying to complete, where the approved route failed and which risk the workaround created. Improve the route, explain the control and retain accountability. Repeating the policy alone rarely explains the obstacle.
Practical guide
Start with the business services you cannot afford to lose and the credible scenarios that threaten them. Compare proposed measures by the risk they address, their dependencies and the effort needed to operate them. A useful priority list explains the decision and gives each action an owner and a verification method.