Our blog features practical articles on cybersecurity and regulations, written in plain language that business owners and managers can understand. We cover specific topics such as NIS2, DORA and CRA requirements, ISO 27001 implementations, incident analysis, phishing, ransomware and best practices for SMEs.
Instead of technical jargon we offer actionable guidance that can be applied to your business straight away. We focus on content you can implement immediately: checklists, threat analyses, SME guides and regular updates on new regulations.
Deepfakes and Voice Phishing: How to Prepare Employees?
Deepfakes and voice phishing mean employees can no longer rely only on voice, video appearance, phone number or an urgent request from a “CEO”, “customer” or “supplier”. The best protection is not detecting AI by ear, but simple procedures: second-channel verification, safety phrases, two-person approval, payment limits, training, ready scenarios and fast reporting of suspicious contacts.
Prepared by: CCyber Editorial Team
Employees should be prepared for deepfakes and voice phishing so they do not have to guess whether a voice or video is real. In practice, the most important rule is: do not make financial, access or data decisions only based on a phone call, voice message, video conference or urgent request. Every unusual request must be verified through a second channel, using a previously known contact method, two-person approval and suspicious-contact reporting. Training should teach not only how to recognize deepfakes, but above all the procedure: stop, verify, confirm, report.
July 2026
A deepfake is artificially generated or manipulated image, audio or video that may look or sound like a real person. In a business context, a deepfake may mean the CEO’s voice, a CFO video, a customer recording, a supplier voice message or a fake part of an online meeting.
A deepfake can be used to:
The key point: a deepfake does not have to be perfect. It only needs to appear in a situation of stress, urgency, authority or financial pressure.
Voice phishing, also known as vishing, is fraud conducted by phone, voice message, messenger, audio recording or online call. The goal is to persuade a person to transfer money, disclose data, share a password, provide an MFA code, reveal company information or take an action they normally would not take.
Voice phishing may be a normal conversation with a fraudster, but it can increasingly be supported by AI: voice cloning, automated speech generation, translation, scenario personalization and combining information from the internet.
Voice is a strong trust signal. When an employee hears a familiar tone, speech pattern and emotion, they may react faster without additional verification.
Attacks often use pressure: “this is urgent”, “do not tell anyone”, “the customer is waiting”, “the board already approved this”, “the payment must go out today”. This is not accidental. Urgency reduces critical thinking.
In the past, phishing was often exposed by language mistakes, strange style and weak personalization. Today, a message, voice or scenario may be fluent, correct and tailored to the company.
The most dangerous scenario combines email, phone, messenger and video call. Example: an employee receives an email from the “CEO”, then a call with a similar voice, then a meeting link.
Information from LinkedIn, company website, social media, podcasts, webinars, video recordings, job offers and press releases may help create a convincing scenario.
Do not train employees that they must independently recognize deepfakes by image or sound quality. This may create a false sense of security. An employee should not be an AI detector.
Teach employees a simple rule:
If the request is urgent, unusual, financial, related to data, password, access or bank account change, stop and verify through a second channel.
The biggest risks are fake payments, bank account changes, urgent invoices, executive impersonation and pressure to bypass procedure.
Their voice, image and communication style may be used for impersonation. Assistants often have access to calendars, documents and contacts.
HR processes personal data, documents, contracts and employee information. It may be targeted with requests for employee lists, payroll data or documents.
The biggest risks are password resets, MFA codes, access granting, administrator access and pressure from the “board”.
An attacker may impersonate a customer, partner or supplier to obtain documents, data, system access or change communication rules.
These teams publish image, voices, recordings, videos and events. They may unintentionally increase the amount of material available for impersonation.
Employees do not need to know technical details of AI models. They need to understand that voice, image, video, messages and communication style can now be faked. Behavior matters more than technology.
Explain:
Evidence to prepare: short employee instruction: “Do not trust voice alone. Verify through a second channel”.
The second channel is the most important control. If the request came by phone, confirm it through another channel. If it came by email, confirm it by phone using a known number. Do not use the number provided in the suspicious message.
Examples:
Evidence to prepare: second-channel verification procedure for payments, data, access and bank account changes.
For selected processes, a short safety phrase or verification question can be used, but it should not be based on public information. Questions like “what is the CEO’s dog called” may be easy to find online.
Good rules:
Evidence to prepare: safety phrase procedure for emergency and high-risk situations.
Payments, bank account changes, administrator access, sensitive data transfers and critical configuration changes should not depend on one person’s decision under phone pressure.
Two-person approval should cover:
Evidence to prepare: two-person authorization procedure and limit list.
Employees should know warning signs, but they cannot rely only on them. No red flags does not mean the contact is genuine.
Evidence to prepare: one-page red flag list for employees.
Simply saying “watch out for deepfakes” is not enough. Employees must practice situations where someone applies pressure and requests action.
Evidence to prepare: exercise scenarios and lessons learned report.
An employee should know where to report a suspicious call, voice message, recording, meeting or request. Reporting should be simple and non-punitive.
The process should answer:
Evidence to prepare: suspicious AI-supported contact reporting procedure.
Not every company can limit publishing, because marketing, sales and recruitment need videos and webinars. However, high-risk materials should be managed consciously.
Check:
The goal is not to disappear from the internet. The goal is to understand that public material may be used to create more convincing impersonation.
Evidence to prepare: review of public audio and video materials of high-risk people.
The best training is not enough if procedures allow one person to execute a large payment after a phone call. A deepfake should be stopped by the process, even if the employee is tired, stressed or convinced they are speaking with a real person.
Processes to secure:
Evidence to prepare: high-risk process list and verification control for each process.
Voice phishing often does not end with the conversation. The fraudster may try to obtain a password, MFA code, account reset or application access.
Technical minimum:
Evidence to prepare: MFA report, password reset procedure and account takeover playbook.
An employee has the right to say: “I need to confirm this according to procedure”. A good security culture supports this behavior even if the request looks urgent.
Do not call back the number provided in a suspicious message. Use a number from the contract, CRM, company contact book or previously confirmed channel.
If the request came by email, replying to the same email is not enough. If it came by phone, continuing the same conversation is not enough.
If the company still decides to take unusual action, the decision should have an owner, justification and approval evidence.
Even if the employee did nothing, the suspicious call itself may indicate a larger campaign against the company.
Training should focus on fraudulent payments, bank account changes, executive impersonation, time pressure and supplier verification.
Training should focus on password resets, MFA codes, access granting, administrator access and pressure from the “board”.
Training should cover personal data protection, fake requests for documents, payroll data, CVs, contracts and employee identity verification.
Training should cover customer impersonation, contact changes, fake document requests, contract pressure and verification of unusual instructions.
The board should understand that its public image, voice and communication style can be used. It should also clearly support employees who pause urgent unusual requests.
An employee should not decide based on whether the voice sounds real. Procedure matters more than impression.
If the request came by phone, it must be confirmed independently. Continuing the same conversation is not verification.
If the board rewards bypassing procedures “because it was urgent”, employees will be afraid to stop suspicious requests.
Finance matters, but deepfakes may target IT, HR, sales, support, suppliers and the board too.
Many companies have procedures for emails, but no rules for unusual requests made during online meetings.
Questions about family, school, job title, pet or city may be available online. They should not be the only verification method.
A false report is better than a real incident without a report. Employees should feel allowed to pause and check.
Every procedure bypass should have an owner, reason and approval. Otherwise exceptions quickly become the new normal.
A services company has 70 employees. The finance director receives a voice message from someone who sounds like the CEO. The request concerns an urgent transfer to a new supplier, and the caller asks not to involve anyone else because the matter is confidential.
The finance employee knows the procedure. They do not execute the payment during the call. They end the contact, check the number in the company contact book and call the CEO through a known channel. It turns out the CEO did not request the payment. The team reports the fraud attempt to IT and security.
After analysis, the company sees that the attacker used public webinar recordings of the CEO and information about a new project posted on LinkedIn. The company updates training, introduces two-person approval for new bank accounts, adds deepfake awareness to onboarding and creates a suspicious-call playbook.
The key result: the employee did not have to decide whether the voice was synthetic. It was enough to follow the procedure.
ccyber.io helps companies prepare employees for deepfakes, voice phishing and AI-supported scams. We do not limit the work to a threat presentation. We build procedures, scenarios, exercises and evidence that actually reduce the risk of wrong decisions under pressure.
We can support your organization with:
The best first step is an AI Social Engineering Readiness Workshop. In a short workshop, the company can identify processes most exposed to deepfakes, prepare a verification procedure and plan first training for finance, IT, HR, sales and the board.
Sometimes they may notice strange elements, but they should not rely on this. Better protection is a procedure: stop, check through a second channel, do not act under pressure and report suspicion.
A deepfake is artificially generated or altered image, voice or video. Voice phishing is fraud conducted through a call or voice message. Voice phishing may use deepfakes, but it does not have to.
Start with finance, accounting, IT, administrators, HR, executive assistants, sales and people with access to customer data or authority to approve payments.
Do not carry out an unusual request during the call. End the conversation and confirm it through a known channel. If the request concerns money, data or access, follow the procedure and report the event.
Not alone. A safety phrase can help, but it should be an additional control. Second-channel verification, two-person approval and exception documentation matter most.
At least understand which recordings are public and who is most exposed. The goal is not to stop marketing, but to manage materials that may make impersonation easier.
Yes. That is why unusual decisions from online meetings, especially about money, access or data, should be confirmed after the meeting through an independent channel.
At least annually and during onboarding. High-risk teams such as finance, IT and HR should be trained more often and after new incidents or procedure changes.
Deepfakes and voice phishing change trust rules inside companies. Voice, face, phone number and urgent message can no longer be enough proof of identity. This is especially true when the request concerns money, data, access, passwords or bypassing procedures.
The best protection is not that an employee “recognizes AI”. The best protection is that the employee knows what to do: stop, confirm through a second channel, use two-person approval and report suspicious contact.
Companies that prepare procedures, train high-risk teams and practice realistic scenarios will be much more resilient against AI-supported fraud. A deepfake may look and sound convincing, but a well-designed process should stop it before a payment, data leak or access grant happens.
Zero Trust for SMEs: A Simple Explanation
Zero Trust for SMEs does not mean buying one expensive tool. It is a practical rule: do not automatically trust a user, device, network or application just because it is “inside the company”. Every access should be verified, limited to the required role, monitored and removable. For SMEs, Zero Trust starts with MFA, access reviews, secure devices, supplier control, backup and logs.
Prepared by: CCyber Editorial Team
Zero Trust is a cybersecurity approach based on a simple rule: do not trust automatically, always verify. In practice, the company does not assume that a user, computer, phone, supplier, application or network is safe only because it belongs to the organization or connects through VPN. Every access to data and systems should be checked, limited to the minimum, policy-based, monitored and regularly reviewed. For SMEs, Zero Trust does not need to mean a large enterprise project. The best start is MFA, account cleanup, access review, administrator control, secure devices, backup, logs and response procedures.
July 2026
Zero Trust is a security approach where the company does not grant trust automatically. Every access request should be checked based on identity, device, application, location, risk, user role and resource type.
The simplest explanation:
Zero Trust does not mean you do not trust people as people. It means the system should not automatically trust any account, device or connection.
Example: an employee signs in to CRM. In a classic model, the company may assume that if the user knows the password and is on VPN, access is safe. In Zero Trust, the company asks more questions:
Zero Trust is a model where every access request is verified, permissions are minimal, risk is evaluated contextually and the company assumes that an account, device or network may be compromised.
You cannot buy “Zero Trust” as one product that solves everything. You can buy tools that support Zero Trust: MFA, Conditional Access, IAM, PAM, EDR, ZTNA, MDM, DLP, SIEM or CASB. But tools without rules and processes are not enough.
Zero Trust is not a message that “we do not trust people”. It is a message that “we do not rely only on a password, network location or good intentions”. We protect employees and the company from the impact of account takeover, phishing, malware and mistakes.
Well-implemented Zero Trust should support work, not paralyze it. The goal is the right access for the right person, from the right device, to the right resource, at the right time.
Zero Trust reduces access takeover risk, but it does not replace backup, incident response planning, training or ransomware recovery.
Small and medium companies increasingly operate as distributed organizations: remote work, cloud, SaaS applications, external IT, suppliers, personal phones, cloud folders, business accounts used outside the office, integrations and automations.
In such an environment, the old “inside the network means safe” model no longer works. The company boundary is not only the office. Data is in Microsoft 365, Google Workspace, CRM, online accounting, cloud, laptops, phones and supplier applications.
The company should check access based on multiple signals, not only a password. Signals may include user, MFA, device, location, application, risk level and data type.
Examples:
The user should have only the access needed for work. Not “just in case”, not “because they needed it once”, not “because it is easier”.
Examples:
Zero Trust assumes that an account, device or network may be compromised. Therefore, the company should limit impact, monitor actions, segment access and have a response plan.
Examples:
You cannot implement Zero Trust if the company does not know who has access to what. The first step is a simple environment map.
List:
Evidence to prepare: simple list of users, devices, applications, suppliers and critical data.
MFA is the most important first Zero Trust step for SMEs. A password can be stolen, but MFA makes it harder to use the password alone to take over an account.
MFA should cover:
Evidence to prepare: MFA report and list of accounts without MFA with plan to close exceptions.
Administrative accounts are the riskiest. If an attacker compromises a normal account, the impact may be limited. If they compromise an administrator, they may change configuration, add users, disable controls and access data.
Check:
Evidence to prepare: administrator report and decisions to reduce roles.
Zero Trust requires access to be justified and current. An access review shows who has access to data, applications and roles, and whether that access is still needed.
Review first:
Evidence to prepare: access review report with decisions: keep, reduce, remove, expire.
Zero Trust is not only about the user. The device is part of the decision too. A company laptop with updates and encryption is not the same as a personal computer without control.
Device minimum:
Evidence to prepare: device list, update status, encryption status and endpoint protection status.
VPN is not automatically secure. In many companies, VPN creates a false sense of security: once connected, the user has too much network access.
Check:
Evidence to prepare: remote access report and VPN user list.
Zero Trust should protect not only systems, but data. In SMEs, the biggest risk often involves cloud folders, customer files, contracts, HR data, finance and technical documentation.
Check:
Evidence to prepare: review of access to sensitive data and sharing links.
Zero Trust assumes that you must observe what is happening. Without logs, the company does not know whether an account was compromised, whether someone downloaded files or whether an administrator made an unusual change.
Minimum monitoring:
Evidence to prepare: list of log sources and basic high-risk alerts.
Suppliers are part of the Zero Trust model. External IT, software house, agency, integrator or consultant should not have unlimited access only because they are a “trusted partner”.
Supplier rules:
Evidence to prepare: supplier register with access to systems and data.
Zero Trust limits incident impact, but it does not remove the need for response. The company should know what to do if an account is compromised, a laptop is lost, ransomware encrypts files or a supplier reports an incident.
Minimum:
Evidence to prepare: response plan and tabletop exercise report.
Start with email, administrators, banking, CRM, cloud, hosting, domain, backup and financial systems.
Legacy protocols and sign-in methods may bypass MFA. Check them especially in email and Microsoft 365.
Keep only the administrators who truly need the role. Use stronger MFA and reviews for high-risk roles.
Former employees, interns, contractors and suppliers should not remain in systems after cooperation ends.
Review access to customer data, finance, HR, backup, cloud and critical applications.
Device inventory, updates, encryption, endpoint protection and response to lost laptops are basic controls.
Check public links, shared folders and guest access to cloud documents.
A supplier should have a named account, MFA, access scope, owner and end date.
Backup should be separated, tested and protected from deletion by a compromised administrator account.
Collect logs for sign-ins, role changes, mail rules, administrator actions and file sharing.
The most common SME Zero Trust scenario is a compromised account. The company must quickly block the account, revoke sessions and check access scope.
Zero Trust is not a one-time project. Every quarter, check MFA, accounts, administrators, guests, suppliers, devices, backup and logs.
For many SMEs, Zero Trust starts in Microsoft 365 or Google Workspace. This is where email, files, meetings, identities, guests and applications live.
In cloud, Zero Trust means that access to resources should not be standing, excessive or based on long-term keys without control.
In SMEs, the IT supplier often has broad access to email, devices, servers, backup, cloud and business systems. This is convenient, but risky.
Backup is part of Zero Trust thinking because you assume an account, server or network may be compromised. An attacker may try to delete or encrypt backups.
The most important rule: a person who can manage normal systems should not automatically be able to delete all backups.
A tool can help, but without an owner, policies, access review and evidence, the company does not implement Zero Trust. It only buys another license.
VPN gives network access, but it does not always limit access to specific applications and data. VPN without MFA, segmentation and logging may increase risk.
The attacker chooses the weakest account. MFA should cover everyone, and administrators should have stronger protection.
Suppliers often have more access than employees. Lack of supplier control contradicts practical Zero Trust.
Zero Trust without regular access review becomes outdated quickly. Permissions accumulate and stop matching real duties.
If the company has no logs, it does not know whether Zero Trust works. It also does not know what happened after account takeover.
An SME does not need to start with a full enterprise architecture. It is better to implement 10 basic controls than plan a perfect model for a year.
Zero Trust changes sign-in and access. Employees should understand that additional verification protects their work, customers and the company.
A services company has 45 employees. It uses Microsoft 365, CRM, online accounting, cloud drive, external IT provider and several SaaS applications. The company has VPN and believes that access is secure because of it.
After a short review, it turns out that MFA works only for some users, there are five Global Administrators, two former suppliers still have guest accounts, public file links have been active for months and backup can be deleted by the same administrator who manages Microsoft 365.
The company does not start with a large project. In the first 30 days, it enables MFA, removes old accounts, reduces administrators and checks backup. In the next 60 days, it performs access review, organizes supplier access, secures devices and enables alerts for unusual sign-ins. After 90 days, it has the first Zero Trust dashboard for the board.
The result: the company still uses the same tools, but access is better controlled. One account takeover no longer gives such broad access, suppliers do not have standing permissions, and the board sees measurable progress.
ccyber.io helps SMEs implement Zero Trust in a practical and staged way. We do not start from theory or tool purchasing. We start from what reduces risk the most: MFA, accounts, administrators, permissions, suppliers, devices, backup and logs.
We can support your organization with:
The best first step is a Zero Trust Discovery Workshop. In a short workshop, the company can identify the biggest access risks, critical accounts and systems, quick actions and a realistic roadmap without wasting budget.
Yes. A small company also uses email, cloud, suppliers, laptops, CRM and customer data. Zero Trust helps reduce the impact of account takeover, phishing, ransomware and excessive permissions.
Not at the start. Many actions can begin with features already available in Microsoft 365, Google Workspace, cloud and endpoint tools. First organize rules, accounts and access.
Start with MFA, a list of users and administrators, inactive account removal, access review, supplier control, backup and basic logs.
No. VPN can be part of remote access, but it does not equal Zero Trust. MFA, access limitation, policies, logs, device control and access reviews are needed.
The traditional model often trusted the internal network. Zero Trust assumes the network may be untrusted, and every access should be verified and limited.
No. Zero Trust reduces access risk, but backup is still needed for ransomware, outages, human error or data loss.
Measure MFA, administrator count, inactive accounts, access reviews, supplier access, device health, logs, backup and response time for compromised accounts.
Yes. Zero Trust provides practical evidence for ISO 27001, SOC 2, NIS2, DORA, cyber insurance and enterprise customers: MFA, access review, logs, supplier control, backup, monitoring and board decisions.
Zero Trust for SMEs does not have to be a complex enterprise project. The simplest rule is: do not automatically trust an account, device, network or supplier. Verify access, limit permissions, monitor actions and prepare incident response.
The best start is MFA, administrator review, inactive account removal, access review, supplier control, device security, backup and logs. These actions can be implemented in stages and materially reduce risk.
Zero Trust is not about making work harder. It is about ensuring that the right people have the right access at the right time, and that one account takeover does not mean takeover of the entire company.
How to Perform an Access Review in a Company?
An access review checks who has access to which systems, data, applications, administrative roles, service accounts and cloud resources, and whether that access is still needed. A good review ends with a decision: keep, reduce, remove, expire or move access into an approval process.
Prepared by: CCyber Editorial Team
An access review should answer one question: does every person, technical account, application, supplier and administrator have exactly the access they still need to work? The simplest process is: prepare the system list, export users and roles, assign business owners, assess access by risk, make decisions, remove unnecessary permissions and keep evidence. A good access review is not only an IT report. It is a business control that reduces the risk of account takeover, data leakage, ransomware, administrator misuse and audit findings.
July 2026
An access review is a control that checks whether users, administrators, suppliers, applications and technical accounts still have justified access to company systems, data and resources. The goal is to remove access that is no longer needed and reduce access that is too broad.
An access review should answer:
Simply put: an access review is access hygiene. Just as a company periodically checks finances, contracts and suppliers, it should periodically check who has access to data and systems.
Access grows over time. An employee changes team, receives new roles, replaces someone in a project, tests an application, helps during an outage, and old permissions remain. After months or years, many people have more access than they actually need.
This creates risk:
An access review reduces the attack surface. It does not prevent every incident, but it limits the impact of account takeover, human error and access misuse.
Frequency depends on risk. Critical systems and administrative roles should be reviewed more often than supporting applications.
Access should also be reviewed after events such as:
Review active employees, their roles, groups, applications and data access. Pay special attention to people who changed job, team or project.
A former employee should not have active access to email, cloud, CRM, repositories, VPN, social media, domain, hosting panel or SaaS applications.
Guests in Microsoft 365, Google Workspace, Slack, Teams, SharePoint, GitHub, Jira or CRM often remain after cooperation ends. This is a common audit issue.
IT providers, software houses, agencies, integrators, accountants, consultants and support providers should have access only to what they need, only during cooperation and only through controlled accounts.
Administrator accounts are the riskiest. Review Global Administrators, cloud administrators, domain administrators, backup administrators, database administrators, repository owners and people who can grant access to others.
Do not review only users. Many permissions come from groups. Check who is in high-risk groups and whether groups are assigned to overly broad roles.
Service accounts, service principals, applications, bots, integrations, API tokens and automations may have broad permissions. Often nobody knows who owns them.
Review CRM, ERP, accounting, HR, project tools, marketing automation, helpdesk, electronic signature, cloud drives, AI tools and communication tools.
In Azure, AWS and Google Cloud, review subscription owners, IAM roles, groups, technical accounts, access keys, public access, cross-account access and data permissions.
Review access to folders with contracts, customer data, financial documentation, HR, source code, backup, technical documentation and strategic information.
First define what exactly you are reviewing. Do not try to review everything at once if the company has never done it before. Start with highest-risk systems.
Scope may include:
Evidence to prepare: access review scope card.
IT can prepare user exports, but it does not always know who truly needs access from a business perspective. The system owner or data owner should make the decision.
Example owners:
Evidence to prepare: system list with business and technical owners.
Prepare a list of users, groups, roles, technical accounts and applications. Without the current state, there is no reliable review.
The export should include:
Evidence to prepare: access state export as of the review start date.
Not every access has the same priority. Start with permissions whose misuse can cause the greatest harm.
Evidence to prepare: high-risk access list.
The system owner must know how to assess access. Without criteria, the review becomes subjective: “let’s keep it, maybe it will be useful”.
Evidence to prepare: access assessment rules and decision criteria.
System owners should confirm access. Ideally, each decision has a status and comment.
If the owner does not respond, do not leave it without a process. Define a rule: manager escalation, reminder, default decision for high-risk access or temporary block until clarified.
Evidence to prepare: system owner decision sheet.
A review without implemented changes has little value. After decisions, access must actually be removed, reduced or changed.
Document:
Evidence to prepare: register of changes made after the review.
Not every access can be removed immediately. Sometimes an exception is needed, but exceptions must be controlled.
An exception should have:
Evidence to prepare: access exception register.
The final report shows that the review was performed and produced results. It is a key document for audit, board, customer or insurer.
The report should include:
Evidence to prepare: final access review report.
An access review should not be a one-time project before an audit. It is a recurring control. After the first review, schedule the next ones.
Evidence to prepare: recurring access review schedule.
In Microsoft 365, administrative roles, groups, guests, SharePoint, Teams, Exchange, enterprise applications and access to sensitive data are especially important.
In cloud environments, access is often more complex than in office applications. Roles may be assigned at organization, account, subscription, project, resource, group or policy level.
Service accounts are often harder than human accounts. Nobody logs in manually, but applications, integrations, scripts and automations use them to work. They may have broad permissions and passwords that have not been rotated for years.
Evidence to prepare: service account, secret and owner register.
Suppliers often have access to systems, data and production environments. Supplier access review should be part of access review, especially when the company uses outsourced IT, MSPs, software houses, accountants, marketing agencies, consultants or integrators.
Evidence to prepare: supplier access register and owner decisions.
IT can prepare data and implement changes, but the business owner should confirm who really needs access.
The company performs a review but does not remove permissions. This creates a false sense of control and weak audit evidence.
Access that may be useful someday should usually be removed and granted again after approval if a real need appears.
Guests and partners often remain in systems long after cooperation ends. This is an easy-to-fix gap.
Service accounts may have more permissions than humans. Without an owner and secret rotation, they create high risk.
Reviewing a low-risk support application is less urgent than reviewing administrators, backup, cloud, finance and customer data.
The auditor will ask not only whether the review happened, but also who made decisions, what changed and which exceptions were accepted.
A one-time review before an audit helps only briefly. Access must be reviewed regularly because the organization changes constantly.
A services company has 80 employees and uses Microsoft 365, CRM, finance system, code repositories, Azure cloud and an external IT provider. Access reviews were performed only before audits, manually and without business owners.
The first real review shows that Microsoft 365 has six Global Administrators, two former suppliers still have guest accounts, the sales team has access to a folder with financial contracts, and a CRM integration service account has administrator permissions without an owner. Some users also have access to projects they have not worked on for over a year.
The company implements a simple process. IT prepares exports, system owners make decisions, and security maintains an exception register and final report. Within 60 days, the company removes former supplier access, reduces administrators, removes inactive accounts, cleans up groups and assigns owners to service accounts.
The result: fewer high-risk accounts, better audit evidence, lower data leakage risk and easier answers to enterprise customer questions. Access review becomes a quarterly control, not an emergency action before audit.
ccyber.io helps companies perform practical access reviews across Microsoft 365, Google Workspace, cloud, SaaS applications, critical systems and external supplier environments. We combine IAM, PAM, cloud security, compliance and audit perspectives.
We can support your organization with:
The best first step is an Access Review Discovery Workshop. In a short workshop, the company can determine which systems carry the highest risk, who should own decisions, which data must be exported and how to run the first review without chaos.
It is a process that checks who has access to systems, data, applications and roles, and whether that access is still needed and aligned with the user’s role.
High-risk access such as administrators, suppliers, customer data, backup and cloud should be reviewed monthly or quarterly. Other applications can be reviewed semiannually or annually depending on risk.
Ideally, the system owner or data owner. IT can prepare the report and implement changes, but the business decision should belong to the person responsible for the process.
Often yes. ISO 27001, SOC 2, NIS2, DORA, cyber insurance and customer requirements often expect access control, regular reviews and evidence of unnecessary permissions removed.
Start with administrators, former employee accounts, guests, suppliers, Microsoft 365 or Google Workspace, backup, finance, CRM and customer data.
Yes. Service accounts often have broad permissions and unclear owners. They should have an owner, justification, permission scope, secret rotation and next review date.
Define an escalation rule. For high-risk access, lack of confirmation should not automatically mean keeping access unchanged.
Keep review scope, user and role exports, owner decisions, change list, exception register, access removal confirmations and final report.
Access review is one of the most important controls in identity, access and cloud security. It helps verify whether employees, administrators, suppliers, applications and service accounts still have access they truly need.
The best review starts with high-risk systems: administrators, cloud, backup, customer data, finance, HR, code repositories and suppliers. Then it requires owner decisions, implemented changes and retained evidence.
A company that regularly reviews access reduces the risk of account takeover, data leakage, access misuse and audit findings. The key is to make the review a recurring risk management process, not a one-time action before an audit.
How to Prepare Your Company for a Post-Incident Audit?
A post-incident audit checks not only what happened, but also how the company responded, what evidence was preserved, which decisions were made, whether data and customer impact were assessed correctly, and whether remediation actions were implemented. Preparation starts with the incident timeline, decision log, technical reports, data breach assessment, communications, backups, logs and improvement plan.
Prepared by: CCyber Editorial Team
A company prepares for a post-incident audit by organizing facts, evidence, decisions and remediation actions. An auditor, customer, insurer, regulator or board will want to see when the incident was detected, what the scope was, which systems and data were affected, who made decisions, what actions were taken, whether logs were preserved, whether data breach impact was assessed, whether communication was controlled and whether the company implemented fixes. The most important documents are the incident timeline, decision log, technical reports, data impact assessment, recovery report, communications, notification evidence, post-incident review and remediation plan.
July 2026
A post-incident audit is a review of facts, decisions, impact and remediation actions after a cyber incident. It may be performed internally by the company, by a customer, auditor, insurer, regulator or external cybersecurity team.
The audit may cover many questions:
A post-incident audit should not be about blaming people. It should be a controlled way to establish facts, close gaps and show that the company manages the situation responsibly.
The board may request a post-incident report to understand the impact on operations, customers, finances, risk and reputation. This report should be business-focused, not only technical.
A customer may request evidence if the incident may have affected its data, service, integration, availability or contractual requirements. In B2B relationships, a post-incident audit often also checks whether contractual notification duties were met.
A cyber insurer may require documentation of the event, costs, decisions, loss scope and evidence that the company met policy conditions such as MFA, backups, updates or an incident response plan.
A regulator may expect information on a data breach, service security, incident notification, remediation actions and compliance evidence. This is especially relevant for GDPR, NIS2, KSC, DORA or sector rules.
An auditor may assess whether the company responded according to procedures, whether controls worked, whether evidence is complete and whether remediation actions were implemented.
The worst time to build evidence is one week after the incident. By then, some logs may be overwritten, people do not remember exact decisions, communication is scattered, and the team tries to reconstruct the timeline from messages and memory.
From the start, maintain:
Evidence to prepare: central incident register maintained from the first report to closure of remediation actions.
First determine what the audit concerns. An audit for a customer, insurer, regulator and board each requires a different preparation.
Determine:
Evidence to prepare: post-incident audit scope card.
The timeline is the most important post-incident document. It shows what happened in sequence and when the company took action.
The timeline should include:
The timeline should clearly separate facts from hypotheses. If something is unknown, mark it as undetermined instead of filling gaps with assumptions.
Evidence to prepare: incident timeline with times, information sources and owner for each entry.
Technical evidence is the foundation for establishing what happened. It may also be needed for customers, insurers, regulators or law enforcement.
Typical technical evidence:
Do not delete or overwrite evidence without consulting the person leading the analysis. In a serious incident, determine whether evidence must be preserved in a form suitable for legal proceedings.
Evidence to prepare: evidence register with location, date, owner and file integrity where used.
The technical report should explain what is known based on evidence. It does not need to use board language, but it should include a business summary.
The technical report should cover:
If the report goes to a customer or regulator, remove information that could unnecessarily disclose sensitive security details or data of other parties. The external version should be reviewed by legal, compliance and communications owners.
Evidence to prepare: technical report and board or customer version where needed.
If the incident may have affected personal data, customer data, trade secrets, financial data or contract-protected data, a separate data impact assessment is needed.
The assessment should determine:
Under GDPR, the company must document the facts, effects and remedial actions. If the company decides notification is not required, that decision should also be documented.
Evidence to prepare: data breach assessment and decision to notify or not notify.
A post-incident audit often checks whether decisions were conscious, documented and made by the right people. Lack of written decisions is a problem, especially when explaining why a system was shut down, why backup was not restored immediately or why a customer was informed at a specific time.
The decision log should include:
Evidence to prepare: crisis decision log.
The audit may cover internal communication, customer communication, supplier communication, insurer communication, legal, regulator or media communication.
Collect:
Communication should be consistent with facts. Do not state that no data was leaked if the company does not yet have evidence. It is better to say what is confirmed, what is being investigated and what actions were taken.
Evidence to prepare: post-incident communication register and approved message versions.
The auditor will want to know whether the company only analyzed the incident or actually limited its impact.
Example actions:
For each action, keep date, person, system and execution evidence.
Evidence to prepare: containment, remediation and recovery action log.
If the incident affected system availability, the audit will ask how the company returned to operation. A statement like “we restored the system” is not enough.
Document:
Evidence to prepare: business recovery report and confirmation that systems returned to operation.
The post-incident review should answer what the company learned and what will change. It is one of the most important audit elements because it shows that the organization not only survived the incident, but improves resilience.
The review should cover:
Evidence to prepare: post-incident review report and remediation action list.
The board needs a report showing business impact, decisions and the improvement plan. It should not receive only a technical log description.
A customer report should be concrete but careful. It should answer legitimate customer questions without disclosing excessive technical detail and without speculation.
Do not send a working technical report to the customer without legal and communication review. The customer version should be aligned with facts, contract and legal duties.
The insurer may ask for evidence concerning loss, costs, cause, scope, actions and meeting policy conditions.
Do not assume all costs will be covered. Check policy terms, exclusions, limits, sublimits, deductible and prior approval requirements.
If the incident affected personal data, the company must prepare a personal data breach assessment. Even if the breach was not notified to the supervisory authority, the decision should be documented.
The key is that the decision should be based on facts and risk to people, not on avoiding formalities.
If the company is or may be covered by NIS2 or national rules implementing it, a post-incident audit may check not only technical response, but also oversight, reporting, decisions, risk management measures and evidence.
If national obligations are still being implemented or interpreted, the company should check current requirements with legal counsel or an appropriate advisor.
Without a timeline, it is hard to answer basic questions: when the incident was detected, when response started, when the customer was informed and when the system was restored.
In an audit, confirmed evidence-based findings must be separated from hypotheses. Speculation can harm communication and report credibility.
Formatting computers, deleting emails, clearing alerts or restoring systems without evidence copies can make analysis and regulator or customer response harder.
After an incident, many decisions seem obvious, but an auditor may ask who made them and on what basis. This must be recorded.
The company must know whether data was only potentially exposed or actually disclosed. Missing data impact assessment is a common problem.
Different message versions for customers, board and employees may create inconsistency. Communication should be approved and archived.
A report without remediation actions looks like a problem description, not risk management. The auditor will ask what was improved.
If the incident involved a supplier system, cloud, hosting or MSP, the company must collect supplier evidence, timeline, actions and confirmations.
A SaaS company serving B2B customers detects a Microsoft 365 administrator account takeover. The attacker had access to email and some files for several hours. The company quickly blocks the account, revokes sessions, removes suspicious mail rules and starts log analysis.
A major customer asks whether its data was affected. The cyber insurer asks for event documentation. The board wants to know whether a data breach must be notified and which actions will reduce recurrence risk.
The company prepares an audit pack: timeline, log report, affected accounts list, file access analysis, data breach assessment, decision log, customer communication, MFA report, remediation action plan and board report. The largest gap turns out to be lack of stronger MFA for administrators and excessive administrative roles.
After 60 days, the company implements phishing-resistant MFA for administrators, reduces roles, introduces quarterly access review, updates the account takeover playbook and runs a tabletop exercise. The post-incident audit does not only answer the customer, but actually improves resilience.
ccyber.io helps companies prepare for post-incident audits in an organized, practical way aligned with board, customer, regulator and insurer expectations. We help collect facts, organize evidence, prepare reports, assess data impact and plan remediation actions.
We can support your organization with:
The best first step is a Post-Incident Audit Readiness Workshop. It helps quickly determine which evidence is missing, which questions the customer or auditor will ask, how to prepare the report and which remediation actions must be closed first.
It is a review of facts, evidence, decisions, impact and remediation actions after a cyber incident. It may be performed by the company, customer, auditor, regulator, insurer or external cyber team.
The most important documents are timeline, decision log, technical report, data impact assessment, communication register, recovery report, post-incident review and remediation plan.
Often yes. A customer report should be shorter, business-focused, fact-based and reviewed by legal and communications owners.
No. The company must assess whether a personal data breach occurred and whether it may create risk to individuals’ rights and freedoms. The decision must be documented.
Yes. Logs are often critical to confirm or exclude access, incident scale, duration and attacker actions.
Be transparent about analysis limitations, describe alternative evidence sources and prepare remediation actions such as longer log retention or enabling missing sources.
Yes. It is one of the best practices. The review helps establish what worked, what did not and what must change.
Start with audit scope, timeline, evidence preservation, decision log, data impact assessment and remediation action list.
A post-incident audit checks more than the technical details of the attack. It checks whether the company knew what it was doing, preserved evidence, made conscious decisions, assessed customer and data impact, and implemented remediation actions.
The most important preparation is the timeline, decision log, technical evidence, data breach assessment, communication register, recovery report, post-incident review and improvement plan. These documents should be created from the first hours of response, not only when a customer or regulator asks for explanations.
The best post-incident audit does not end with a report. It ends with risk reduction: better MFA, backups, logs, incident response plan, supplier control, training, monitoring and clear board decisions.
How to Document Cybersecurity Training for Audit Purposes?
Documenting cybersecurity training for audit purposes is not only about an attendance list. A company should have a training programme, training scope, target groups, materials, participant list, test results, completion confirmations, effectiveness metrics, remediation actions and evidence of recurring improvement. Auditors want to see that training is planned, measurable, repeatable and linked to company risk.
Prepared by: CCyber Editorial Team
Cybersecurity training for audit purposes should be documented in a way that proves three things: the training happened, the right people participated and the training was aligned with company risk. An attendance list alone is usually not enough. A good evidence pack should include the training programme, date, trainer, target group, scope, materials, participant list, completion confirmations, knowledge test results, effectiveness metrics, remediation actions and evidence that training is regularly updated. The key is to connect training with employee roles, risk, incidents and audit requirements.
July 2026
Cybersecurity training should reduce the risk of human mistakes, phishing, payment fraud, data leakage, unsafe AI use, weak password management and poor incident response. However, an auditor does not assess only whether the company says it trains people. The auditor checks whether the company can prove it.
Good training documentation helps to:
Simply put: training without evidence may be hard to defend in an audit. Evidence without real training is also weak. Both are needed.
The auditor usually does not want to see only slides. The auditor wants to understand whether the organization has a controlled training process. Well-prepared documentation should show that training is planned, delivered, measured and improved.
For each of these questions, the company should have a document, report, system entry, list, confirmation or decision. Audit should not rely on one person’s memory.
Not every training session needs the same level of formality, but every material cybersecurity training should have evidence. The strongest focus should be on mandatory training, high-risk role training and training required by regulations, standards or customers.
Evidence to prepare: training matrix by roles and audit requirements.
The plan shows that training was not random. It should cover a year or at least a quarter.
The plan should include:
Evidence: annual cybersecurity training plan.
The agenda shows what participants were supposed to learn. This matters because the auditor may check whether the right topics were covered.
The agenda should include:
Evidence: training agenda and scope description.
Materials show which content was delivered. They may include slides, recording, workshop scenario, instruction, e-learning, quiz, case study or checklist.
Materials should have:
Evidence: complete training materials with version number.
The participant list shows who attended training. It should be accurate but not excessive. Do not collect data you do not need.
The list may include:
Evidence: participant list or learning platform report.
An auditor may distinguish between “invited to training” and “completed training”. Completion status matters more than the invitation itself.
Confirmation may include:
Evidence: training completion report.
A test is not always mandatory, but it helps strongly in an audit. It shows that the company did not only deliver content, but checked understanding.
The test should show:
Evidence: knowledge test results report.
Training should have metrics. Without metrics, the company does not know whether training works.
Example metrics:
Evidence: training effectiveness report.
If some employees did not complete training or test results are weak, the company should have a remediation plan. Lack of response to results is a common audit problem.
Actions may include:
Evidence: post-training remediation action register.
Training is often linked to policies such as the information security policy, password policy, AI policy, remote work policy or incident reporting procedure. It is useful to have evidence that the employee acknowledged the applicable rules.
Evidence: policy and procedure acknowledgment confirmation.
The auditor may ask whether training is current. If materials have not changed for years, they may not cover new risks such as AI scams, deepfakes, prompt injection, MFA fatigue or new fraud schemes.
Evidence: history of training programme and materials updates.
For ISO 27001, the key is to show that training is part of systematic information security management. Evidence should be linked to risk, competence, awareness, policies and control effectiveness.
Prepare:
For NIS2, board training, cyber hygiene, employee training and the ability to identify risks and assess cyber risk management practices are especially important. Documentation should show that training is regular and linked to risk management.
Prepare:
For SOC 2, the auditor often expects evidence that employees are trained on security, confidentiality, privacy, procedures and responsibilities. Evidence consistency over time matters.
Prepare:
In the GDPR context, training may concern personal data protection, confidentiality, breach reporting, work with customer data and minimization principles. At the same time, training documentation itself contains personal data and must be protected.
Prepare:
The insurer may ask about phishing training, security awareness, phishing simulations and response procedures. Keep evidence that confirms questionnaire answers.
Prepare:
The easiest way to manage documentation is an evidence matrix. It shows which training is required, for whom, how often and which evidence must be retained.
Name: Phishing and social engineering for employees.
Group: all employees.
Frequency: onboarding and annually.
Evidence: agenda, materials, participant list, knowledge test, completion report, overdue participant list, remediation actions.
Risk: account takeover, fraudulent payment, data leakage, ransomware.
Owner: security or HR in cooperation with IT.
There is no single universal answer for every company and audit. The retention period should follow the purpose, legal, regulatory, contractual and audit requirements. At the same time, training documentation contains personal data.
The key point: do not keep documentation forever if there is no purpose. Define retention period, owner, storage location and deletion rules.
Evidence should be easy to find during an audit, but protected from unauthorized access. The worst model is evidence scattered across mailboxes, private drives and folders owned by different people.
Evidence to prepare: training documentation storage procedure and list of authorized people.
Onboarding is one of the most important moments. A new employee receives access to email, systems, data and customers. Auditors often check whether new employees were trained before receiving full access or shortly after joining.
Board training should be documented differently from employee training. The auditor may expect evidence that the board understands risks, makes decisions and oversees the cybersecurity programme.
The greatest value is not the certificate of attendance. The greatest value is evidence that the training led to decisions: budget, roadmap, risk owner, incident plan or gap analysis.
Phishing simulations can be a good tool, but they must be run responsibly. The goal is not to shame employees, but to improve organizational resilience.
Evidence: phishing simulation report with conclusions and educational actions.
An attendance list says who attended. It does not say what the training covered, whether the participant understood the material and what the company did with the results.
Training should follow company risk. Accounting exposed to payment fraud, administrators and the board require different training.
The auditor may ask what the company did with people who did not complete training. A process for reminders, escalation and completion is needed.
If materials have no date and version, it is hard to prove which content was current at the training date.
Training should not end only with attendance confirmation. Test results, phishing reports, mistakes and remediation actions should be measured.
Training documentation contains personal data. Define the purpose, data scope, retention period and access.
Training evidence should be stored in one controlled place. Scattered evidence makes audits harder and increases the risk of losing documents.
If the company had a phishing incident, data leakage or AI-related issue, the training programme should be updated.
A SaaS company is preparing for SOC 2 and a large enterprise customer. It has cybersecurity training, but evidence is scattered: some attendance lists are in email, some in HR, some in an e-learning platform, and training materials have no date or version.
During preparation, the company finds that 18 percent of employees do not have annual training completion confirmation, new employees did not always complete onboarding training, and the development team did not have separate secure development training. The board had a NIS2 briefing, but there is no decision note.
The company organizes the process in 60 days. It creates a training matrix, central evidence repository, versioned materials, completion reports, knowledge tests and reminder process. A separate board pack is created: agenda, materials, participant list, decisions and action plan. A secure SDLC training is created for developers.
During the audit, the company does not need to search for documents. It shows the auditor a requirements matrix, completion report, materials, test results, exception list and remediation actions. Training stops being a formality and becomes a measurable security control.
ccyber.io helps companies prepare cybersecurity training documentation for audits, customers, cyber insurance and regulatory requirements. We combine security, compliance, HR, board and auditor perspectives.
We can support your organization with:
The best first step is a Training Evidence Readiness Review. In a short review, the company can check whether evidence is complete, where gaps exist, which training must be completed and how to prepare an audit pack without chaos.
Usually not. Attendance matters, but it is better to have agenda, materials, scope, test results, completion confirmation, metrics and remediation actions.
Not every one, but a test helps a lot in audits. For mandatory training, phishing, NIS2, GDPR and high-risk roles, testing is a good practice.
Use a platform report: participant, date, duration, completion status, test score, number of attempts and material version. The report should be exportable for audit.
Prepare agenda, materials, participant list, signatures or attendance confirmations, meeting note, knowledge test and post-training report.
It depends on the purpose, regulations, contracts and audit cycle. Define the retention period in a procedure and do not keep data longer than necessary.
Yes, if they can be linked to a specific person. Access must be restricted, data minimization applied and data retained only as long as justified.
Use reminders, escalation to the manager, re-training and documented completion. No response to overdue training can become an audit issue.
Start with a role-based training matrix, required evidence list, central repository and gap report: who has not completed training, what is missing and by when it must be completed.
Documenting cybersecurity training for audit purposes should show not only attendance, but the full process: plan, scope, materials, participants, completion, tests, effectiveness, remediation and updates.
The best evidence pack answers simple questions: who was trained, when, on what, why, with which result and what the company did with the results. This makes training a real security control, not just a formality.
Well-prepared documentation makes ISO 27001, SOC 2, NIS2, KSC, DORA, GDPR, cyber insurance and enterprise customer reviews easier. The key is that evidence should be current, complete, stored in one place and linked to company risk.
We write about regulations such as NIS2, DORA, CRA and ISO 27001, cybersecurity for SMEs and critical infrastructure, as well as cyber hygiene, emerging threats and building security awareness within organisations.
Every article delivers practical knowledge - no jargon, just concrete steps you can act on to effectively protect your data, people and business continuity.