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.
How to Train Employees in Cybersecurity to Actually Change Behavior?
Effective cybersecurity training is not a once-a-year presentation. It should change specific behaviors: reporting phishing, verifying unusual requests through a second channel, protecting MFA codes, handling data safely, being cautious with payments and responding to incidents. The best programmes are short, recurring, practical, role-based and measured not only by attendance, but by real employee behavior.
Prepared by: CCyber Editorial Team
Employees should be trained in cybersecurity so that after training they know what to do in a specific situation, not only what definitions mean. The goal is not “training completion”, but behavior change: reporting suspicious messages, not sharing MFA codes, verifying urgent requests through a second channel, protecting customer data, being careful with attachments, following payment procedures and reporting mistakes quickly. Good training is short, practical, recurring, role-based and connected with procedures and technology. The key rule is: do not teach people only to recognize attacks, teach them to respond safely even when the attack looks credible.
July 2026
Many companies treat cybersecurity training as a formality. Once a year, employees watch a presentation, click through a test and the topic is considered complete. The problem is that this model often builds declarative knowledge, but does not change daily decisions.
Training fails to change behavior when it is:
Cyber awareness is not about making every employee know everything about cybersecurity. It is about making the safe decision at the critical moment.
Behavior change means that an employee does something differently in a specific situation. It is not only about knowing what phishing, ransomware or MFA mean. It is about using the right response.
Understood this way, training is closer to practicing habits than giving a lecture.
Before preparing materials, the company should answer one question: which employee decisions matter most to us?
Evidence to prepare: list of 5 to 10 security behaviors the company wants to change in the next 90 days.
A well-prepared phishing email, deepfake or fake phone call may not always be recognizable. The employee should know the response: stop, verify through a second channel, do not share the code, report.
Finance needs payment and bank account scenarios. HR needs personal data and recruitment scenarios. IT needs password reset and MFA scenarios. The board needs authority abuse, deepfake and crisis communication scenarios.
Short monthly or quarterly modules are better than one long annual presentation. Reminders help maintain habits.
An employee will remember a situation that looks like daily work: invoice, Teams, customer call, supplier attachment, password reset request.
Public shaming after a phishing simulation destroys reporting culture. The employee should feel that quick reporting is a success, not a failure.
If the company measures only clicks, employees learn to avoid mistakes. If the company measures reporting, employees learn to help detect attacks.
Many attacks work through urgency and authority. Training should teach that urgency does not remove procedures.
Training without procedures is weak. The employee must know where to report phishing, how to confirm a payment, how to verify a supplier and what to do after clicking.
Managers create culture. If managers require speed at the expense of procedures, training will fail. If managers praise reporting and verification, employees repeat that behavior.
Every incident, simulation and report should improve the training programme. Training must evolve with threats and the company’s way of working.
First, check where an employee decision can cause real loss.
High-risk processes:
Evidence to prepare: map of high-risk processes and employee groups assigned to them.
For every process, define which behavior should happen.
Evidence to prepare: behavior table: situation, right response, process owner, metric.
General training should be short and practical. Its goal is to create a shared language across the company.
General training scope:
Evidence to prepare: general training materials and decision test after training.
Role-based training should focus on decisions in a specific team. This has the strongest impact on behavior.
Evidence to prepare: training scenarios mapped to roles and processes.
You cannot expect reporting if the process is hard. The employee should have a simple path: email button, Teams channel, security address or form.
A good reporting process should be:
Evidence to prepare: reporting procedure and suspicious situation report metrics.
Practice changes behavior more effectively than presentation alone. The employee should see a scenario, make a decision and receive feedback.
Evidence to prepare: exercise report, results, findings and remediation actions.
Attendance is a formal metric. It does not show whether someone will act safely. Measure what the company wants to change.
Example metrics:
Evidence to prepare: cyber awareness dashboard with behavior metrics.
If an employee reports a suspicious message and never receives a response, they will stop reporting. Feedback reinforces behavior.
Good practices:
Evidence to prepare: examples of feedback communication and monthly reporting summary.
Fear may grab attention, but it rarely builds lasting habits. An employee who is afraid may hide mistakes. An employee who understands the procedure and knows the company supports reporting reacts faster.
Phishing simulations can be useful, but only if they are done wisely. The goal should not be to catch employees making mistakes. The goal should be to practice response and improve reporting.
The best simulation is one after which the company knows more: which messages are hardest, who reports, how fast the team responds and which procedure needs improvement.
This is one of the most important behaviors. Employees can become a distributed early warning system if they have a simple and safe way to report.
An employee should know that an MFA code is private. It is not shared by phone, email, Teams, SMS or messenger.
Every unusual request for money, data, access, password, document or bank account change should be confirmed through another previously known channel.
In payments, bank account changes, access granting and confidential data transfer, a second person reduces the risk of acting under pressure.
Employees should know which data must not be pasted into unapproved AI tools and where to request approval for a new tool.
If an employee clicked, shared data, approved login or sent a file, the most important action is fast reporting. Hiding the mistake increases losses.
The company collects attendance and test scores, but does not know whether employees behave more safely.
The same material for board, finance, HR and helpdesk does not address the real risks of these roles.
The employee knows they should be careful, but does not know where to report a problem or how to confirm an unusual request.
This discourages reporting. Employees will hide mistakes, and the company will lose response time.
Clicks matter, but they do not show full resilience. Reports, response time and correct decisions also matter.
If managers do not support procedures, employees will choose speed over security.
Habits fade. Short recurring reminders are needed, especially when new threats appear.
Training does not replace MFA, email filters, DMARC, backup, EDR, DLP or good processes. The best result comes from combining people, technology and procedures.
A services company runs mandatory cybersecurity training once a year. Employees pass the test, but in practice little changes. Phishing is rarely reported, finance sometimes confirms bank account changes by email, and helpdesk receives password reset calls without a clear verification procedure.
The company changes its approach. Instead of another long presentation, it creates a behavior programme. The first three goals are: increase phishing reporting, introduce second-channel verification for bank account changes and stop MFA code sharing by phone. Training becomes short and role-based. Finance practices a fake invoice. IT practices password reset fraud. The board practices a call from someone sounding like the CFO.
After 90 days, the company has more reports, fewer procedure exceptions, first exercise reports and a clear board dashboard. The most important change is not that everyone knows the definition of phishing. It is that employees started pausing, verifying and reporting.
ccyber.io helps companies build cybersecurity training that changes behavior, not only meets a formal requirement. We combine training, procedures, scenarios, metrics, simulations and audit evidence.
We can support your organization with:
The best first step is a Cyber Awareness Behavior Change Workshop. In a short workshop, the company can define which behaviors need to change, which teams are most exposed, which procedures need improvement and how to measure real training impact.
No. One training may meet a formal requirement, but it rarely changes habits. Short recurring modules and exercises work better.
Changing a specific behavior. Example: an employee reports phishing, does not share an MFA code, confirms unusual requests through a second channel and does not bypass payment procedure.
They can be if they are part of a wider programme, do not shame employees, measure reporting and lead to practical conclusions. A simulation alone is not enough.
Measure behavior: reports, second-channel use, response time, correct decisions in exercises, number of exceptions and remediation actions.
The board should practice authority abuse, deepfake, voice cloning, post-incident communication and a culture where procedures matter more than apparent urgency.
Do not shame employees. Praise reports, give feedback and clearly communicate that quick mistake reporting helps reduce losses.
Finance, accounting, IT, helpdesk, HR, sales, customer service, executive assistants and people who approve payments, access or data transfers.
Start with 5 behaviors you want to change in 90 days. Then prepare short role-based training, a simple reporting channel, second-channel procedure and behavior metrics.
Cybersecurity training truly changes behavior when it is practical, recurring, role-based and connected with procedures. The goal is not for employees to remember definitions. The goal is for them to know what to do in a critical situation.
The most important behaviors are reporting suspicious messages, protecting MFA codes, second-channel verification, following payment procedures, handling data safely and reporting mistakes quickly. These are the behaviors that reduce real losses.
The best rule is: training should teach the decisions the company wants to see in practice. Only then does cyber awareness stop being a presentation and become part of daily work.
AI Scams: How to Prepare Employees for Next-Generation Fraud?
AI-supported scams are harder to spot because they may use fluent language, personalization, voice cloning, deepfakes, fake documents, automated conversations and analysis of public company information. Employees should not be trained only to “detect AI”, but mainly to respond safely: stop pressure, verify through a second channel, report suspicious contacts, protect MFA codes, follow payment procedures and use two-person approval.
Prepared by: CCyber Editorial Team
AI scams are a new generation of familiar attacks: phishing, vishing, CEO fraud, fake invoices, investment scams, supplier impersonation, fake IT support, deepfakes and voice cloning. The difference is that AI helps fraudsters act faster, more convincingly and more personally. Employees should not be trained only to detect “whether this is AI”. That is not enough. They should know how to respond to urgent requests for payment, data, password, MFA code, bank account change, system access or document transfer. The key rules are: stop, do not act under pressure, verify through a second channel, do not share MFA codes, use two-person approval and report suspicious contacts.
July 2026
AI scams are fraud attempts where the attacker uses artificial intelligence to prepare, personalize, automate or make an attack more credible. The target is still a human: employee, customer, board member, accounting team, helpdesk, HR or supplier.
AI can help the attacker in several stages:
The key point is that AI does not need to be perfect for an attack to work. It only needs to lower the employee’s caution and create pressure for quick action.
In the past, phishing was often exposed by grammar mistakes, strange translations and unnatural style. AI can write fluently, correctly and in the recipient’s language.
The attack may refer to a real project, customer, conference, LinkedIn post, company publication, organizational structure or public statement by a board member.
Voice cloning may make a caller sound like a CEO, CFO, customer, supplier or family member.
A deepfake may use a face, voice or video to make a meeting, message or instruction appear credible.
The fraudster can prepare many versions of a message, many languages and many scenarios faster than before.
A correct message, familiar tone and no typos no longer mean safety. Employees must look at the request, context and procedure, not only message appearance.
An email or message that looks credible and tries to make an employee click a link, open an attachment, provide data, sign in to a fake page or perform an action.
AI helps write error-free messages, adapt them to a department and create more convincing context.
Spear phishing targets a specific person or team. AI may use public information about the employee, company, customer, role and projects to make the message look like a natural part of work.
Vishing is voice phishing. The attacker calls or sends a voice message to steal money, MFA code, access or data. Voice cloning may make the caller sound like someone the victim knows.
An attack may use fake image and voice during a video conference. The goal may be approving a transfer, sending a document, changing a procedure or granting access.
AI can help create a convincing supplier email, correct invoice, fake confirmation or message requesting a bank account change.
An employee receives an urgent request from someone impersonating the CEO, CFO or manager. AI can help match style, tone, language and pressure to the company’s real communication.
The fraudster pretends to be helpdesk, supplier, administrator or consultant. They ask for an MFA code, tool installation, password reset, login approval or screen sharing.
A candidate, recruiter or fake portal may use AI to create credible profiles, documents, conversations and job offers. Risks include personal data, documents and payments.
A fraudster may use a deepfake of a known person, fake recommendations, automated chat and profit promises to push the victim into investment or data sharing.
The attacker may impersonate a customer, supplier or business partner. They ask for documents, address changes, a new bank account, portal access or data confirmation.
“This must be done now”, “the customer is waiting”, “the payment must go out today”, “the board already approved it”.
“Do not tell anyone”, “this is confidential”, “do not involve the team”, “we will handle paperwork later”.
Someone moves from corporate email to private messenger, new phone number or private email address.
A supplier requests a bank account change, especially urgently or without standard documentation.
Nobody should ask for an MFA code by phone, email, SMS, Teams or messenger.
CEO, CFO or manager asks for something unusual, urgent or outside procedure.
The message looks correct, but the link leads to an unusual domain, and the attachment requires macros, login or file download.
The caller insists that you must not call back, ask a manager or verify through another channel.
An employee may not always recognize whether a message, voice or image was created with AI. Training should therefore teach safe response, not only signs of artificiality.
Key behaviors:
General training is necessary, but AI scams work better when tailored to the role. Finance should practice different scenarios than HR, IT or sales.
A second channel means an unusual request must be confirmed through an independent, previously known contact method. Do not use the phone number, link or email address provided in the suspicious conversation.
Second-channel examples:
Payments, bank account changes, access granting, critical account reset, sensitive data transfer and configuration changes should not depend on one person acting under pressure.
Two-person approval should cover:
An employee should be able to report a suspicious email, phone call, voice message, SMS, chat or online meeting in a simple way. The harder reporting is, the fewer reports the company will receive.
Good reporting should be:
The employee should know exactly what to do in the first 60 seconds. Deepfake theory is not enough.
Simple response model:
Even if the caller sounds familiar, a request for money, data, access or code must be verified.
The fraudster wants the victim to act quickly. Real urgency should not remove procedures.
MFA codes are never shared. A push notification that the user did not trigger should not be approved.
When in doubt, open the system through a known address, bookmark or app, not through a link in the message.
Payment detail changes always require independent verification and approval.
A scam can work even when the recording is not perfect if there is pressure, authority and confusion.
An employee who reports a suspicious contact helps protect the company. Even if they are wrong, the report is valuable.
Employees should understand that AI can create text, voice, images, documents and convincing scam scenarios. You do not need to start with technical model details.
The best training uses scenarios close to real work: invoice, Teams, call from CEO, password reset, supplier, customer, CV, offer, code repository.
The warning sign list should be short and memorable: pressure, secrecy, channel change, code request, new bank account, procedure bypass, refusal to verify.
Training must show what the employee should do step by step. Practicing the response is better than only talking about it.
Exercises should include email, SMS, phone call, voice message, deepfake meeting and fake document.
The test should measure decisions, not definitions. Example: “what do you do when the CFO calls asking for an urgent transfer to a new account?”.
One annual training is not enough. Short reminders, micro-exercises and communications after new incidents work better.
Describes when and how an unusual request must be confirmed. It should cover payments, access, data, passwords, MFA codes and documents.
Defines who can approve a transfer, what amount threshold applies, when a second person is needed and how to confirm a new recipient.
Every bank account change should be confirmed through a known channel and approved by an authorized person.
Helpdesk should have a clear identity verification process and a ban on password reset based only on a phone call or message.
Employees should know where to report an email, call, SMS, voice message, deepfake or fake meeting.
The company should know who informs the board, legal team, DPO, customer, insurer or supplier.
AI scams change quickly. One annual training is not enough, especially for high-risk teams.
The employee does not need to recognize the technology. They need to apply verification procedure.
If employees are afraid to report mistakes, the company loses the most important source of attack information.
The board is often used as an authority element in scams. It should clearly communicate that procedures matter more than urgency.
Training does not replace firm rules: second channel, two people, amount threshold and new bank account verification.
AI scams may arrive through phone, SMS, Teams, WhatsApp, LinkedIn, online meeting, document, ad or voice message.
Helpdesk is a target because it can reset passwords, help with access and manage accounts. It needs separate exercises.
Without metrics, the company does not know whether training changed behavior or only happened formally.
A manufacturing company runs standard phishing training once a year. A few months later, a finance employee receives a call from someone who sounds like a board member. The caller asks for an urgent transfer to a new supplier and says the matter is confidential. The employee is unsure, but does not know whether they can end the call and whom to ask.
After the event, the company changes its approach. It introduces second-channel verification, two-person approval for bank account changes, a ban on sharing MFA codes, a simple reporting channel and short role-based exercises. Finance practices urgent payments and fake invoices. IT practices password reset fraud. HR practices fake candidates and deepfake interviews.
After 90 days, reporting increases, which is a good sign. Employees start asking, confirming and reporting unusual situations. The company no longer relies on someone “detecting AI”. It relies on procedures that work even when the scam looks credible.
ccyber.io helps companies prepare employees for next-generation scams: AI-supported phishing, vishing, voice cloning, deepfakes, fake invoices, CEO fraud and MFA code theft. We do not focus only on theory. We build scenarios, procedures, exercises and training evidence.
We can support your organization with:
The best first step is an AI Scam Readiness Workshop. In a short workshop, the company can identify which teams are most exposed, which scenarios are realistic, which procedures need change and which training will create the biggest effect in the first 30 days.
They are fraud attempts where the attacker uses artificial intelligence to prepare, personalize, automate or make an attack more credible. They may include phishing, vishing, deepfake, fake invoices and CEO fraud.
Sometimes, but this should not be relied on. A stronger protection is procedure: second channel, two-person approval, no MFA code sharing and suspicious contact reporting.
Start with finance, accounting, IT, helpdesk, HR, executive assistants, sales and people who can approve payments, access or data transfers.
No. AI scams go beyond email. You need to practice phone calls, SMS, messengers, online meetings, voice messages, fake documents and deepfakes.
Do not act under pressure. If a request concerns money, data, access, password or MFA code, verify it through a second channel and report the suspicious situation.
No. It is enough to create time pressure, authority, confusion and credible context. That is why procedures matter more than judging recording quality.
Measure reports, correct reactions, test results, second-channel verification use, procedure exceptions and response time to suspicious contact.
Start with a scenario map, short red flag list, second-channel rule, MFA code sharing ban, payment procedure and first training for high-risk teams.
AI scams are not science fiction. They are practical use of artificial intelligence to strengthen familiar fraud: phishing, vishing, fake invoices, CEO fraud, deepfakes and access theft. Attacks become more fluent, more personal and harder to spot at first glance.
The best answer is not expecting every employee to recognize AI. The best answer is preparing people for the right behavior: stop, verify through a second channel, do not share MFA codes, do not bypass procedures, report suspicious situations and use two-person approval.
Companies that train employees on real scenarios detect scams faster, reduce losses and build a culture where caution is not an obstacle to work, but part of professional behavior.
Microsoft 365 Backup: Why Cloud Alone Is Not Enough
Microsoft 365 provides high availability, infrastructure resilience and multiple recovery mechanisms, but cloud alone does not replace a backup strategy. The company is still responsible for data, accounts, permissions, retention, user mistakes, malicious deletions, ransomware, incident recovery and audit evidence. Microsoft 365 backup should cover Exchange, OneDrive, SharePoint, Teams, configuration, permissions, restore testing, RTO, RPO and protection against backup deletion.
Prepared by: CCyber Editorial Team
Microsoft 365 is a highly available cloud service, but this does not mean the company does not need a backup strategy. Microsoft is responsible for infrastructure, service availability and platform resilience, but the organization remains responsible for its data, users, accounts, configuration, permissions, retention, mistakes, malicious activity, ransomware and audit requirements. Recycle bin, versioning, retention and eDiscovery are important, but they are not the same as full operational backup. A good Microsoft 365 backup should answer: what do we protect, for how long, how quickly can we restore, who can delete backups, is the backup resistant to administrator account compromise and when was the last restore test performed.
July 2026
Many companies assume that because data is in Microsoft 365, it is automatically safe. This is partly true, but only in relation to service resilience. Microsoft manages infrastructure, replication, availability, data centers and many platform protection mechanisms. The company must still manage what happens to its data and accounts.
Cloud can protect against a server failure in a local server room, but it may not always protect the company against:
The key difference: Microsoft is responsible for the platform operation, while the company is responsible for data use, configuration, access, retention, classification and recovery readiness.
Microsoft 365 works under a shared responsibility model. This means part of responsibility sits with the cloud provider and part with the customer.
Microsoft 365 backup should not be treated as distrust of cloud. It is part of the customer’s responsibility for their own data and business continuity.
Microsoft 365 has many mechanisms that help recover data. These are very important features. The problem starts when the company treats them as full backup.
Recycle bin helps recover recently deleted files, folders or items. However, it has limited retention time and may not help if data was deleted long ago, removed from many locations or deleted as part of malicious activity.
Versioning helps restore an earlier file version. It can be useful after wrong edits or overwrite. It is not a full strategy for restoring an entire site, mailbox, team or large part of a tenant after an incident.
Retention mainly supports information governance, compliance, eDiscovery and preservation requirements. It can preserve copies of content according to policy, but it does not always answer the need for fast operational restore after ransomware or wrong deletion.
eDiscovery helps find and preserve data for legal, audit or investigation purposes. It is not a tool for quickly restoring operations for sales, finance or customer service.
Backup should make it possible to restore data to a usable state after a mistake, incident, malicious action or process failure. Good backup is designed around RTO, RPO, data scope, copy protection, testing and restore procedures.
Microsoft 365 is not one database. It is a set of connected services. Backup should reflect how the company actually works.
Teams is especially important because Teams data is distributed. Channel files are stored in SharePoint, chat files usually in OneDrive, and teams are connected with Microsoft 365 Groups, permissions, channels, meetings and other services. Therefore, Teams backup must be understood more broadly than “backup the Teams app”.
In practice, check whether backup covers:
Backing up data is one thing. Preserving knowledge about configuration and permissions is also important. After an incident, the company must know not only which files to recover, but also who should have access to them.
It is worth documenting or backing up:
A user deletes a folder, file, message, team, channel or site. The issue becomes serious when the mistake is discovered late or affects many items.
An employee, former employee, supplier or compromised account intentionally deletes data. This may affect customer files, mailboxes, documentation, project teams or financial data.
Ransomware may encrypt local files synchronized with OneDrive and SharePoint. Encrypted versions may then synchronize to cloud, and the issue may affect many libraries and users.
An attacker with administrator access can change configuration, delete data, modify retention rules, disable controls, remove backup or make recovery harder.
An incorrect retention policy may delete data faster than expected or keep data too long and create legal risk.
After an employee leaves, the company may lose access to important files in OneDrive if it has no process for ownership transfer, archiving and backup.
Migration into Microsoft 365, between tenants or between SharePoint structures may lead to loss of metadata, permissions, versions or some data.
Deleting a team may affect the group, SharePoint, files, permissions and project context. Restoring files alone may not restore the full collaboration structure.
RTO, or Recovery Time Objective, means the maximum acceptable restore time. It answers: how quickly must we restore data or service?
Example: finance must recover the mailbox and payment files within 4 hours.
RPO, or Recovery Point Objective, means the maximum acceptable data loss in time. It answers: which point in time must we be able to return to?
Example: the company accepts losing no more than 4 hours of work on sales documents.
Without RTO and RPO, backup is only a technical copy. With RTO and RPO, backup becomes part of business continuity. The board does not need “we have a copy”. The board needs “we can recover critical data within the required time”.
Backup is used to restore data after a mistake, incident, ransomware, deletion or process failure. It focuses on operational recovery.
Archiving is used for long-term data preservation, often for legal, tax, historical or business reasons.
Retention defines how long data should be kept or when it should be deleted. It matters for compliance and information governance.
The company confuses retention with backup. Retention may help preserve data, but it does not always provide fast, convenient and complete operational recovery after an incident.
The company should know which services and data are protected. Do not assume backup covers everything.
Backup should create restore points at a frequency aligned with risk. Finance may need a different RPO than the marketing archive.
The company should be able to restore a single email, file, folder, mailbox, site, OneDrive account or larger data set.
After ransomware, the company may need to restore many accounts, mailboxes, libraries or sites. The tool should support scale, not only one-file recovery.
Backup should be protected from the user account, normal administrator and attacker. MFA, roles, administrative separation, alerts and mechanisms making backup deletion harder are especially important.
If the same administrative accounts manage production and backup, an attacker may try to take over both. Backup should have a separate access model and stronger controls.
Backup without testing is an assumption, not evidence. The company should regularly verify that it can restore data within the required time.
Backup should generate evidence: what is protected, when backup ran, when restore ran, who approved it and what the test result was.
Backup must consider data location, retention, GDPR, customer contracts, industry requirements and data deletion rules.
The company should know who decides on restore, who approves scope, how to check data cleanliness and how to avoid restoring the problem.
The company may use native Microsoft mechanisms, Microsoft 365 Backup or partner and third-party solutions. There is no single answer for everyone. The choice should follow risk, data scope, RTO, RPO, legal requirements, budget and IT operating capability.
Do not ask “which tool is best?”. Ask: which recovery scenario must we handle, within what time, for which data and with what evidence?
Not all data has the same value. Start with data the company cannot operate without.
Evidence to prepare: critical Microsoft 365 data list with business owners.
Determine where the data actually is. Teams, SharePoint, OneDrive and Exchange are connected, and one business process may use several locations at once.
Check:
Evidence to prepare: Microsoft 365 data location map.
For every critical process, define how quickly data must be restored and how much data loss the company can accept.
Example:
Evidence to prepare: RTO and RPO table for Microsoft 365 data.
The scope should follow risk and data criticality. Do not automatically assume everything needs the same protection level.
Evidence to prepare: formal Microsoft 365 backup scope.
Backup should be protected as seriously as the production system, and sometimes even more strongly. An account that can delete backup is a highest-risk account.
Define:
Evidence to prepare: Microsoft 365 backup role and permission matrix.
Backup retention should follow operational and legal needs. Short retention may not be enough if a problem is discovered after several months. Too-long retention may increase costs and data risk.
Define:
Evidence to prepare: Microsoft 365 backup retention policy.
Restore should not be improvised during an incident. The company should have procedures for the most common scenarios.
Evidence to prepare: Microsoft 365 restore playbook.
The test should verify not only whether the tool works, but whether the company can restore data according to RTO and RPO.
Test:
Evidence to prepare: restore test report with time, scope, result and findings.
Backup is part of incident response. In ransomware, account takeover or mass deletion, the company must know what to do before restore.
The plan should cover:
Evidence to prepare: Microsoft 365 incident playbook with backup and restore section.
Ransomware in Microsoft 365 usually does not mean that Microsoft 365 as a service stops working. The problem may be that the attacker encrypts files on a user device and the changed files synchronize with OneDrive or SharePoint. Another scenario is account takeover and mass deletion or overwrite.
Employee departure is a common data loss scenario. Many important files live in the user’s OneDrive, not in a formal team site. If the company has no data handover process, it may lose project knowledge, contracts, analyses and work history.
Backup does not replace offboarding, but it can significantly reduce data loss risk after a key person leaves.
For compliance, what matters is not only that data exists. What matters is whether the company can prove control over recovery process, retention, access and exceptions.
Microsoft 365 has many resilience and recovery mechanisms, but the company still needs to define its own backup, restore, retention and data responsibility strategy.
Retention helps meet data preservation requirements, but it does not always provide fast and convenient operational recovery after an incident.
The company has a backup tool, but never checked whether it can restore a mailbox, site or data after mass deletion.
If the backup administrator has no MFA or can delete copies without additional controls, backup may be destroyed during an attack.
Many important data sets are in OneDrive. Without offboarding, the company may lose data after deleting a user account.
Teams is connected to SharePoint, OneDrive, Exchange and Microsoft 365 Groups. Backing up files alone may not be enough to restore collaboration context.
Without RTO and RPO, the company does not know whether backup meets business needs. It may have a copy but restore too slowly.
The board often learns about backup problems only after an incident. Regular reporting enables earlier risk and budget decisions.
Some incidents are detected after weeks or months. Retention that is too short may prevent return to a healthy data point.
After ransomware, clicking restore is not enough. Accounts, devices, sessions and data must not still be under attacker control.
A services company uses Microsoft 365 as its main work environment. Email is in Exchange Online, customer documents are in SharePoint, employee files are in OneDrive, and projects run in Teams. The board assumes that because everything is in cloud, backup is not needed.
After one user account is compromised, files in several SharePoint libraries are massively deleted and overwritten. IT tries to recover data from recycle bin and versions, but quickly discovers that the issue affects many locations, some data is already outside simple recovery scope, and the company has no list of critical sites, RTO, RPO or restore procedure.
After the incident, the company implements a Microsoft 365 backup strategy. It creates a critical data list, covers Exchange, OneDrive and SharePoint with backup, organizes Teams, restricts administrator roles, enables MFA, prepares a restore playbook and performs quarterly restore tests.
The most important change: the board stops asking “is the data in cloud?”. It starts asking “can we recover it within the required time and do we have evidence?”.
ccyber.io helps companies design and test a Microsoft 365 backup strategy. We combine security, business continuity, compliance, identity, access and real ransomware scenario perspectives.
We can support your organization with:
The best first step is a Microsoft 365 Backup Readiness Workshop. In a short workshop, the company can determine which data is critical, what is already protected, what is missing, which RTO and RPO are realistic and which restore test should be performed first.
Microsoft 365 has resilience, retention, recycle bin, versioning and recovery mechanisms, but the company should have its own backup and restore strategy aligned with risk, RTO, RPO and audit requirements.
Not as a full backup strategy. Recycle bin helps with recent deletions, but it has time, operational and scenario limitations.
Not fully. Retention matters for compliance, eDiscovery and information governance, but it does not always provide fast and complete operational restore after an incident.
At minimum, critical Exchange mailboxes, OneDrive accounts, SharePoint sites, Teams-related data, shared mailboxes, groups and selected metadata and permissions.
Yes. Teams uses multiple Microsoft 365 services. Files are connected with SharePoint and OneDrive, while teams are connected with groups, channels, memberships and permissions.
At least quarterly for critical data and after major changes, migrations, new backup tool deployment or retention changes.
Only selected people, with MFA, separate roles, activity logging, least privilege and additional approval for high-risk operations.
Start with critical data list, RTO and RPO, review of current recovery mechanisms, restore test and assessment of whether the current model meets company needs.
Microsoft 365 is a very strong cloud platform, but cloud alone does not replace a backup strategy. The company remains responsible for data, accounts, permissions, retention, recovery, testing and evidence of readiness.
Recycle bin, versioning, retention and eDiscovery are needed, but they should not be confused with operational backup. Microsoft 365 backup must address business scenarios: accidental deletion, malicious action, ransomware, account takeover, employee departure, Teams deletion and bulk data recovery.
The key rule is: do not ask only whether data is in Microsoft 365. Ask whether the company can recover it within the required time, from the right point, safely and with evidence for the board, customer, auditor or insurer.
Just-in-Time Access and Just-Enough-Access: A Simple Explanation for IT and Compliance Teams
Just-in-Time Access means access granted only for the time needed, while Just-Enough-Access means access limited only to the necessary permissions, resources or commands. Together, they help reduce standing privileges for administrators, suppliers, developers and service accounts. For IT, this lowers account takeover risk. For compliance, it proves that privileged access is justified, approved, time-bound, monitored and regularly reviewed.
Prepared by: CCyber Editorial Team
Just-in-Time Access and Just-Enough-Access are two simple ways to reduce privileged access risk. Just-in-Time Access answers: when can the user have permissions and for how long? Just-Enough-Access answers: which exact permissions are needed and for what? In practice, an administrator, supplier, developer or operator should not have standing, broad access “just in case”. They should receive access only when they have a specific task, only for a defined time, only to the right scope and only after meeting conditions such as MFA, justification, approval, trusted device, session logging and later review.
July 2026
Just-in-Time Access, or JIT, means access granted only when needed. The user does not have standing administrator privileges all the time. Instead, they can activate a role for a defined period, for example 30 minutes, 2 hours or one day, to perform a specific task.
Example: an administrator does not have the Global Administrator role permanently active. They are eligible, meaning they can request role activation. To activate it, they must use MFA, provide justification, sometimes obtain approval and complete the task within a defined time. After that time, the role expires.
Just-Enough-Access, or JEA, means access limited only to what is needed to perform the task. In practice, this may mean a narrow role, restricted resource scope, selected commands only, read-only instead of write access or access only to one application, subscription, folder, database or environment.
In Microsoft environments, the term Just Enough Administration is also used. It is a specific PowerShell technology that delegates administration so that a user can perform only approved commands and functions. In this article, we use Just-Enough-Access more broadly: as a principle of minimum access scope that can apply to cloud, systems, applications, data, code, servers and production environments.
Concerns access time.
Example: an administrator can have the Owner role in Azure for only 2 hours after MFA and approval.
Concerns access scope.
Example: an administrator can manage only one resource group, not the whole subscription.
The best model is: the user gets only the access they need, only when they need it and only for the time required to complete the task.
JIT limits the time of risk. JEA limits the scope of risk.
Standing broad permissions are convenient, but risky. If an account with such permissions is compromised, the attacker does not need to wait for approval or activate a role. They can act immediately.
JIT and JEA do not replace MFA, logs, segmentation, backup or monitoring. However, they are among the most important controls for reducing the impact of account compromise.
Compliance teams often ask: who has access, who approved it, whether it is still needed and whether the company can prove what the user did. JIT and JEA make these questions easier to answer.
JIT and JEA help show that the company does not grant access “forever” and “to everything”, but manages access according to risk, business need and least privilege.
An administrator needs to change configuration in Azure. Normally, they do not have the Owner role active. They open the access management system, select the role, provide justification, pass MFA and request activation for 2 hours. After the work is complete, the role expires automatically.
A supplier needs access to a customer server to update an application. The system owner approves access for a specific maintenance window. The supplier logs in through VPN with MFA and a jump server. The session is logged and access expires when the window ends.
A developer needs to investigate a production incident. They do not have standing production access. They receive read-only access to logs for 60 minutes. If a configuration change is required, it needs separate approval.
An administrator needs to restore selected data. The backup management role is activated temporarily. Deleting backups requires additional approval and is separately alerted.
A helpdesk employee can reset passwords for users in a specific organizational unit, but cannot change MFA configuration, administrator roles or conditional access rules.
An operator can restart a specific service on a server, but cannot browse files, change system configuration, add users or run arbitrary scripts.
A developer can view application logs and metrics, but cannot change data, run migrations, modify configuration or export the entire database.
An ERP supplier can access only the ERP environment, only through an approved path and only for service functions. They do not have access to email, backup, cloud or other systems.
A strong JIT and JEA implementation should meet both goals: reduce technical risk and create control evidence.
First, know who has high-risk access. Without this, JIT and JEA will be implemented randomly.
List:
Evidence to prepare: privileged access register with owner, scope, time and last use.
Not all access requires the same control. Treat marketing admin access differently from Global Administrator, production, backup or cloud root access.
Evidence to prepare: access risk classification.
JIT should be mandatory where standing permissions create high risk. Not everything must be changed immediately. Start with the highest-risk roles.
Evidence to prepare: list of roles covered by JIT and exception list with justification.
JEA should be mandatory where a role is too broad for the task. This is especially important in helpdesk, application administration, DevOps, production and supplier access.
Evidence to prepare: minimal role and permission scope matrix.
JIT should have conditions. Time-bound activation alone is not enough if anyone can activate a role without MFA, justification and logs.
Evidence to prepare: JIT activation policy for high-risk roles.
JEA requires specifics. It is not enough to write “least privilege”. The exact allowed actions must be defined.
Evidence to prepare: JEA role card with allowed and prohibited actions.
JIT and JEA without logs are weak from audit and incident response perspectives. The company should know when access was activated, who used it, what they did and whether actions matched the purpose.
Log:
Evidence to prepare: privileged access activation and usage report.
JIT reduces standing role risk, but it does not remove the need for access review. A person may still be eligible to activate a role even after changing teams or finishing a project.
The review should cover:
Evidence to prepare: access review for eligible roles, active roles and exceptions.
JIT and JEA must not lock the company out during a crisis. Emergency accounts, break glass procedures and emergency access rules are needed.
The emergency process should define:
Evidence to prepare: break glass procedure and emergency account test report.
Start with Global Administrator, Privileged Role Administrator, Security Administrator, Exchange Administrator, SharePoint Administrator, Intune Administrator and data access roles. Implement JIT for high-risk roles, MFA, access reviews and fewer global administrators.
Review Owner, Contributor, User Access Administrator, Key Vault Administrator, Backup Contributor and network roles. Decide which roles can be eligible, which require approval and which can be scoped to a specific subscription, resource group or resource.
Review root accounts, AdministratorAccess roles, cross-account roles, IAM, KMS access, Secrets Manager, CloudTrail, backup and production access. Reduce standing roles, use temporary sessions, permission boundaries, SCPs and narrowly scoped roles.
Review Owner, Editor, IAM Admin, Service Account Admin, Organization Admin, Project IAM Admin and secret access. Reduce broad roles, use time-bound access where available and narrow scope to project, folder or resource.
Review Domain Admins, Enterprise Admins, local administrators, administrative workstations, service accounts, supplier accounts and remote access. Introduce separate administrative accounts, administration tiering, JEA for PowerShell where useful and administrator activity monitoring.
Review who can deploy to production, change pipelines, modify secrets, disable tests, approve releases and read production data. Introduce JIT for production access and JEA for roles: log read, deploy, rollback, configuration change and secret access.
The user activates access only for one hour, but during that hour has full control over the whole tenant, subscription or production environment. This is still high risk.
The role is limited, but access is standing. If the account is compromised, the attacker can use it for a long time.
Activations without a reason are weak for audit and make misuse detection harder.
For critical roles, MFA alone may not be enough. Sometimes approval by the system owner or security is needed.
The company knows access was activated, but does not know what the user did. This is insufficient during incidents and audits.
A “temporary” exception often becomes standing access if nobody defines a review date.
Suppliers often have broad access, but are missed in JIT and JEA programmes. This is one of the most common weak spots.
An overly restrictive model without emergency accounts may make incident or outage response harder.
Compliance should be involved from the start so required evidence is collected during the process, not reconstructed before audit.
A SaaS company has IT, DevOps and several external suppliers. A review shows that 12 people have standing production access, 5 people have Owner in the cloud, a supplier has standing VPN access, and compliance has no evidence why these accesses are needed.
The company starts with a pilot. For cloud Owner roles, it introduces JIT: 2-hour activation, MFA, justification and approval. For developers, it introduces JEA: production log access is read-only by default, while configuration changes require approved change management. For the supplier, it introduces access through a jump server, only for a maintenance window, with session logging.
After 90 days, standing permissions are reduced, compliance has activation and approval reports, and IT has fewer exceptions and better visibility into administrator actions. The company can still move fast, but high-risk access is time-bound, scoped and auditable.
ccyber.io helps companies design and implement Just-in-Time Access and Just-Enough-Access in a practical, auditable and risk-based way. We combine IT, security, compliance, suppliers, cloud and business process perspectives.
We can support your organization with:
The best first step is a JIT and JEA Access Control Workshop. In a short workshop, the company can identify the riskiest roles, where standing access exists, which permissions are too broad, which evidence is needed for audit and which quick changes reduce risk in the first 30 days.
It is access granted only for the time needed to perform a specific task. After the time ends, access expires automatically or is removed.
It is access limited to the minimum scope: only the required roles, resources, commands, systems and actions. The user does not receive more permissions than the task requires.
JIT limits access time. JEA limits access scope.
Not always. If a user receives very broad permissions for a short time, risk is still high. Time-bound access should be combined with minimum scope.
Not always. Limited but standing access can still be used by an attacker after account compromise. For high-risk roles, JIT should also be used.
Usually the system owner, manager, security team or process owner. For critical roles, approval should be independent from the person requesting access.
Access request, justification, approval, activation time, role scope, MFA, activity logs, access expiration, access review and exception list.
Start with a privileged role list, MFA, removal of unjustified standing access, selecting first roles for JIT and preparing a least-privilege role matrix.
Just-in-Time Access and Just-Enough-Access are two pillars of modern privileged access management. JIT limits the time during which a user has high privileges. JEA limits the scope of what the user can do.
For IT, this means lower risk of account takeover, privilege misuse, misconfiguration and ransomware. For compliance, this means better evidence, easier audits and clear answers to: who had access, why, for how long, to what and what they did.
The best rule is: privileged access should be justified, minimal, time-bound, approved, monitored and regularly reviewed. If a company implements this first for the highest-risk roles, it quickly reduces the attack surface and improves audit readiness.
PAM Basics: 9 Controls That Protect Privileged Accounts
PAM, or Privileged Access Management, helps protect administrator accounts, service accounts, supplier access, cloud roles and other high-risk permissions. PAM basics are not only a password vault. They are 9 practical controls: account inventory, separate admin accounts, MFA, least privilege, time-bound access, secure passwords and secrets, controlled admin workstations, logs and monitoring, and recurring access reviews.
Prepared by: CCyber Editorial Team
PAM, or Privileged Access Management, is a set of processes and controls that protect accounts with elevated permissions. This includes administrators, service accounts, IT suppliers, cloud roles, access to backup, financial systems, infrastructure, Microsoft 365, Azure, AWS, Google Cloud, VPN, databases, code repositories and production environments. The main goal of PAM is simple: one compromised account must not mean full company compromise. A basic PAM programme should include 9 controls: account inventory, separate admin accounts, MFA, least privilege, time-bound access, secure password and secret management, controlled admin workstations, logs and monitoring, and recurring access reviews with fast access removal.
July 2026
PAM stands for Privileged Access Management. In practice, it protects accounts, roles and sessions that can change system configuration, create users, delete data, disable security controls, modify infrastructure, manage backup or access critical data.
Examples of privileged access:
PAM answers: who has the highest privileges, why they have them, when they may use them, how they authenticate, whether their actions are logged and who regularly checks whether this access is still needed.
A privileged account can do much more than a normal user account. If an attacker compromises a normal employee account, the impact may be limited. If they compromise an administrator, they may add new accounts, disable MFA, change mail rules, delete backups, download data, install malware or prepare ransomware.
The biggest privileged account risks are:
IAM, or Identity and Access Management, covers general identity and access management. It applies to all users, applications, groups, roles, login, SSO, MFA, onboarding, offboarding and permissions.
PAM focuses on the highest-risk access. It applies to administrators, service accounts, cloud roles, break glass accounts, suppliers, privileged passwords, administrative sessions and actions that can change the security of the entire organization.
IAM answers: who has access to what?
PAM answers: who has access that can take over, change or stop critical systems?
You cannot protect accounts you do not know about. The first PAM control is a complete list of privileged accounts, roles and accesses.
List:
For each account, define:
Evidence to prepare: privileged account and role register with owners and last review date.
An administrator should not use the same account for daily work and administrative actions. An account used for email, internet, messaging and office work is more exposed to phishing, malware and user mistakes.
A good model:
Example: John Smith has a normal account for email and meetings, and an admin.john.smith account for administrative actions. The administrative account has stronger MFA, logs and restricted login options.
Evidence to prepare: administrator list confirming separate normal and administrative accounts.
MFA for privileged accounts is the minimum. An administrator password can be stolen, but MFA makes it harder to use the password alone to take over access.
MFA should cover:
For highest-risk roles, consider stronger methods than SMS, such as authenticator apps, hardware keys, passkeys or access conditions based on device and location.
Evidence to prepare: MFA report for privileged accounts and exception list with closure date.
An account should have only the permissions needed for a specific task. Global Administrator should not be the default solution for every administrative need.
Apply these rules:
Example: a person managing users does not need to be a Global Administrator. They can have a narrower role that allows only the required actions.
Evidence to prepare: privileged role matrix with justification and permission scope.
Standing administrative access is convenient, but risky. A better model is time-bound access: the administrator activates a role when needed, for a defined time, with justification and often with approval.
Time-bound access should cover:
Good practices:
Evidence to prepare: privileged role activation report with time, justification and approvals.
PAM is not only about people. Many risks involve service accounts, secrets, API tokens, SSH keys, database passwords and credentials used by applications.
The biggest problems:
The control should include:
Evidence to prepare: register of service accounts, secrets and privileged passwords with owner and last rotation date.
Even the best MFA is not enough if an administrator signs in to critical systems from a computer used for email, internet and private tools. Privileged accounts should be used from controlled devices and secure access paths.
Possible controls:
SMEs do not always need to start with a full privileged access workstation model. A good first step is: administration only from company-managed, secured, updated and monitored devices.
Evidence to prepare: list of allowed administrative devices and access paths for high-risk roles.
The company should know who used privileged access, when, from which device, for what reason and what actions they performed. Without logs, audit, incident response and misuse investigation are difficult.
Log and monitor:
For suppliers and critical systems, consider session recording or at least full activity logging. Logs should also be protected against modification by the same administrator whose actions are logged.
Evidence to prepare: list of PAM log sources, sample alerts and administrator activity report.
PAM does not work without regular review. Permissions accumulate. People change roles. Suppliers finish projects. Service accounts remain after old applications. That is why privileged access must be reviewed and removed regularly.
Access review should cover:
Emergency accounts, often called break glass accounts, are an important element. They are used when normal administrative access does not work, for example MFA outage or incorrect Conditional Access configuration. Emergency accounts should be few, strongly protected, monitored and used only in crisis situations.
Evidence to prepare: access review report, removed permissions list, emergency account list and usage procedure.
An SME does not need to start with a full PAM platform. Many actions can begin with existing tool configuration, simple registers, policies and recurring reviews.
Privileged access is especially important in the cloud because one role may control a subscription, project, account, database, storage, secrets, network or logs.
Suppliers often have broad access because they help maintain IT, cloud, ERP, financial systems, backup, network, OT or applications. This is convenient, but risky.
A good test: if you end cooperation with a supplier today, do you know which accounts, passwords, tokens, VPN access and roles must be disabled?
Service accounts and secrets are often weaker than human accounts. They rarely have MFA, often have long lifetimes, may be saved in scripts and sometimes nobody knows who owns them.
Many people have top roles “just in case”. This increases the risk of full organization compromise after one account is breached.
An administrative account used for email and internet is more exposed to phishing, malware and session theft.
The attacker will choose the weakest account. MFA should cover all privileged accounts and supplier remote access.
Technical accounts live for years, have broad permissions and nobody knows whether they are still needed.
A supplier has VPN, administrator password and access to many systems without end date. This is operational and audit risk.
After an incident, the company does not know who added an account, changed configuration, disabled MFA or deleted backup.
A password vault will not solve the problem if the company still has too many administrators, no access review and no supplier access rules.
The company may accidentally lock itself out of tenants, cloud or critical systems. Emergency accounts should exist, but be strongly controlled.
Employees change roles, leave the company and suppliers finish projects. Privileged access must be removed quickly and documented.
A services company has 90 employees and uses Microsoft 365, Azure, a financial system, code repositories and an external IT supplier. After a short review, it turns out there are seven Global Administrators, some administrators use the same accounts for email and system configuration, two former suppliers still have active accounts and service accounts have no owners.
The company does not start with a large PAM platform. First, it lists administrators, enables MFA, reduces Global Administrators, removes former supplier accounts and creates separate administrative accounts. Then it implements time-bound access for cloud roles, service account review, basic activation logs and access review procedure.
After 90 days, the company has fewer standing permissions, better supplier access visibility, MFA for administrators, a service account list and a board report. It is still not full enterprise PAM, but administrator account takeover risk is much lower.
ccyber.io helps companies implement PAM in a practical, staged and risk-based way. We do not start by buying a tool. We start with who has the highest permissions, why they have them, whether MFA works, whether access is standing, whether logs exist and whether someone regularly checks whether access is still needed.
We can support your organization with:
The best first step is a PAM Basics Workshop. In a short workshop, the company can identify which accounts are most risky, how many administrators exist, where MFA is missing, which accesses are standing, which service accounts require review and which quick actions reduce risk in the first 30 days.
PAM is Privileged Access Management. It covers protection of administrator accounts, service accounts, secrets, supplier access, cloud roles and administrative sessions.
No. A password vault can be part of PAM, but full PAM also includes MFA, least privilege, time-bound access, approvals, monitoring, sessions, access reviews and offboarding.
Start with administrator list, MFA, separate administrative accounts, reducing top roles, removing old supplier accounts and first access review.
Yes, for administrative actions, a separate account is recommended. The normal account is for daily work, while the administrative account is only for tasks requiring higher privileges.
Yes. Service accounts, API tokens, SSH keys and secrets often have very high privileges, so they should have an owner, minimum permissions, rotation and monitoring.
It is access granted only for the time required to complete a task. After the time ends, the role expires automatically, which reduces standing privilege risk.
They should not have standing access without justification. Supplier access should be named, time-bound, approved, protected with MFA, logged and removable quickly.
Privileged account register, MFA report, access review report, administrator list, service account list, activity logs, supplier access procedure and emergency account procedure.
PAM protects the riskiest type of company access: accounts and roles that can change configuration, delete data, disable security controls, manage backup or take over critical systems. That is why PAM should be treated as a security foundation, not an optional feature for large organizations.
PAM basics are 9 controls: account inventory, separate administrative accounts, MFA, least privilege, time-bound access, secure passwords and secrets, controlled administrative environment, logs and monitoring, and access review with strong offboarding.
The best rule is: privileged access should be rare, justified, time-bound, monitored and removed when no longer needed. Then, even if an account is attacked, the impact is much easier to contain.
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.