Guides

When companies start building products with AI, or integrating language models into existing systems, new forms of security risks emerge. Traditional security tools are built for predictable systems where the same input always produces the same output and the logic can be inspected line by line. But AI systems don’t work that way. They behave non-deterministically, meaning the response can vary even with identical input, and they accept instructions in plain text rather than code. This opens up attack surfaces that classical security frameworks aren’t built for.

This guide provides a concrete overview of the most important risks, how they are tested, and what you can do to reduce them.

‍

Why AI security is different

In a traditional web-based system, there is clear logic to test: code that does things, responses that follow rules, behavior that can be predicted. Security work is about finding gaps in that logic. AI systems work differently in a few ways that actually matter for security.

Behavior varies. The model can give different answers to the same question, which makes it difficult to define what is normal, and even harder to guarantee that security controls hold in all situations.

Training data is a possible attack vector. An attacker who can influence what the model is trained on can shape how it behaves at a fundamental level. This is called data poisoning and is one of the harder problems to detect after the fact.

Instructions arrive as plain text. Users write to the model in natural language, and the model cannot reliably distinguish between legitimate instructions and malicious ones. This creates an attack surface that lives in the content itself, not in the code.

There is also a responsibility gap that is easy to miss. Providers like OpenAI and Anthropic are responsible for their infrastructure and their model, but how you handle inputs, what tools the model has access to, and how you filter output, that is your responsibility. Most serious incidents occur in that gap.

‍

The biggest risks: OWASP Top 10 for LLMs

OWASP, the organization behind the well-known security lists for web applications, has published a list specifically for AI systems and language models. The list was updated in 2025 and reflects how the threat landscape has changed as more companies have started building with AI. Here are the ten risks.

Prompt Injection

An attacker smuggles instructions into text that the model processes, thereby hijacking the model’s behavior. This can happen directly via the user’s own inputs, or indirectly via documents and web pages that the model retrieves and reads. Prompt injection is the most widespread attack class against AI systems and currently has no general technical solution.

Sensitive Information Disclosure

The model leaks sensitive information, for example internal instructions governing its behavior, confidential documents in its context, or data from other users. The risk increases in systems that retrieve information from external sources, or where multiple users share the same context.

Supply Chain

AI applications depend on a long chain of components: model API, databases, plugins, training data. If any part of the chain is compromised, an attacker can influence the model’s behavior without touching the application code directly.

Data and Model Poisoning

The data used to train or fine-tune the model is manipulated with the intent to affect how it behaves. This can involve planting hidden behaviors triggered by specific inputs, or systematically skewing the model’s responses in a particular direction. Difficult to detect, and difficult to remediate once it has occurred.

Improper Output Handling

The model’s responses are treated as trusted data and passed on without sufficient control. This opens the door to downstream attacks: if the model generates JavaScript that is rendered directly in a browser, or SQL that is run against a database without filtering, an attacker can control what actually executes.

Excessive Agency

The model is given more permissions and tools than the task requires. If an attack succeeds, it is the model’s actual permissions that determine how much damage can be done. An AI agent that can write files, send emails, and call external services is a significantly more serious problem than one that can only read.

System Prompt Leakage

The system prompt, the underlying instructions that govern how the model behaves, is exposed to users or attackers. These instructions often contain sensitive logic: security rules, internal guidelines, API keys, and permission structures. If they leak, attackers gain a detailed map of how the system works.

Vector and Embedding Weaknesses

Many AI systems use RAG, meaning the model retrieves relevant information from an external knowledge base before responding. That knowledge base is indexed as numerical vectors (embeddings). Vulnerabilities here include malicious vectors being inserted into the database to affect what information is retrieved, or crafted queries tricking the system into returning data that should not be accessible.

Misinformation

The model generates incorrect statements with high confidence. In business applications, this can lead to poor decisions, legal issues, or damaged trust. The risk is greatest in systems where the model’s responses are presented as facts without source references and without a human verification step.

Unbounded Consumption

The application allows unregulated resource usage. An attacker can craft queries that trigger extremely costly computations, drive up costs significantly, or cause operational disruptions. In services with variable per-API-call pricing, this can have a direct financial impact.

Read more in our article about: Security in LLM Applications – What Businesses Need to Know

Vulnerabilities in RAG systems and agents

RAG systems and AI agents introduce additional risks that deserve their own section.

RAG — Retrieval-Augmented Generation — is a technique where the model retrieves information from an external knowledge base before responding. This makes the system more fact-based and current, but also opens the door to an indirect variant of prompt injection: an attacker who can influence the content of documents the model reads can steer what the model says, without the user doing anything wrong. Retrieval manipulation is a similar attack where a crafted query tricks the retrieval logic into returning the wrong information.

AI agents are systems where the model doesn’t just respond but also acts, for example searching for information, writing code, sending emails, or calling external services. This amplifies the effect of all other risks. The more things an agent is allowed to do, the more an attacker can accomplish if they succeed in hijacking its behavior. The basic rule is simple but easy to ignore during development: give the agent only the permissions that are actually needed for the task.

‍

Data protection and AI: GDPR and the EU AI Act

Integrating AI into business systems raises legal questions that go beyond pure security testing, and it is worth having the basics clear.

The EU AI Act entered into force in phases from 2024, with most requirements taking effect during 2026 and 2027, depending on the type of system. The law classifies AI systems by risk, and requirements scale with the classification. High-risk systems, those used in credit decisions, recruitment, or medical diagnosis, have the heaviest requirements: risk management, technical documentation, and ongoing monitoring. All companies that develop or use AI systems within the EU are affected by the law to some extent, even if it is the high-risk category that carries the most concrete obligations.

The GDPR question is primarily about what happens when you send data to an external AI provider. Since 2023, the EU-US Data Privacy Framework has provided a structure that allows the transfer of personal data to certified US companies, including the major AI providers, without needing to establish separate agreements for each transfer.

What is worth checking is that your specific provider is actually certified, and that the agreements in place cover the data you actually send. The legal landscape around international data transfers has changed several times in recent years and may change again.

The practical advice is simple: don’t send more data than necessary. Personal data and confidential business data should be kept out of the model’s context as much as possible, and when that isn’t possible, you should know exactly which agreement governs the processing.

‍

How do you test AI security?

Security testing an AI system requires a different methodology than classical penetration testing. Classical pen testing tests known logic in known code. AI testing tests how a system behaves when exposed to adversarial inputs, and that requires both technical breadth and an understanding of how language models work.

Prompt injection testing is the foundation. It involves systematically trying to hijack the model’s behavior via inputs: direct instructions, role-play scenarios, and instructions embedded in documents the model reads. It cannot be fully automated, and manual testing by someone who understands how models behave is required.

Jailbreak testing examines whether the model’s safety filters can be bypassed to get it to generate responses it would normally block. Methods change rapidly and require ongoing updates to test cases.

Data leakage testing examines whether an attacker can manipulate the model into disclosing information from its context or connected data sources to an unauthorized party.

Adversarial testing involves crafted inputs designed to manipulate the model’s classification or responses in a specific way, often subtly enough that it is not visible to a regular user.

Cyloq’s approach is grounded in offensive security expertise applied to AI-specific attack methods. We test your AI systems the same way an attacker would, using OWASP Top 10 for LLMs as one of our frameworks.

‍

Practical measures for businesses

There are a number of measures that meaningfully reduce the attack surface and should be in place in any system with AI integration in production.

‍

• Validate inputs. Filter and control what users send before it reaches the model. This doesn’t eliminate prompt injection risk entirely, but it reduces the attack surface.

‍

• Control what the model passes on. Never treat the model’s responses as trusted code or data. Sanitize and validate output before it is rendered in a browser or passed to other systems.

‍

• Limit permissions. Give the model and any agents only the rights that are actually needed for the task. The less an attack can accomplish, the better.

‍

• Monitor prompt patterns. Log and analyze inputs on an ongoing basis to detect anomalous behavior and active attempts to manipulate the model. This gives you visibility and a record if something happens.

‍

• Think carefully about what data is sent. Personal data and confidential business data should be kept outside the model’s context as much as possible. Only send what is actually needed to complete the task.

‍

• Test regularly. AI systems change quickly: model versions are updated, instructions are adjusted, new features are added. Test at every major change and at least once a year for systems in production.

NIS2 is the EU's directive on cybersecurity. It sets clearer requirements, covers more sectors, and gives supervisory authorities real power to act when compliance falls short. If your company doesn't already know whether you're covered by NIS2, now is the time to find out.

This guide walks through what NIS2 means in practice, whether your organization is subject to the law, what you concretely need to do, and what happens if you don't.

NIS2 in brief

NIS2 (Directive on Security of Network and Information Systems, EU 2022/2555) is the EU's updated cybersecurity framework. It replaces NIS1 from 2016 and entered into force at EU level in January 2023. In Sweden, the directive was implemented through the Cybersecurity Act (2025:1506), which applies from 15 January 2026. At the same time, the previous Swedish NIS Act was repealed.

Compared to its predecessor NIS1, the differences are significant. The number of regulated sectors has more than doubled, from seven to eighteen. Requirements are sharper and more concrete. Fines are substantial. And leadership can no longer keep its distance from these issues.

In Sweden, supervision is divided by sector. The Swedish Civil Contingencies Agency (MCF) coordinates the work at national level, but it is sector-specific authorities that monitor compliance in practice, including:

‍

• The Swedish Transport Agency for transport

• Finansinspektionen for the financial sector

• The Swedish Energy Agency for energy

• The Swedish Post and Telecom Authority (PTS) for electronic communications
  
  Read more: What is NIS2 and what does it mean for you?

‍

Does your company fall under NIS2?

The Cybersecurity Act divides organizations into two categories: essential and important. The requirements for security measures are broadly the same for both, but supervision differs. Essential entities are subject to ongoing, proactive supervision. Important entities are reviewed reactively, meaning only when there are indications of shortcomings.

Essential sectors include energy (electricity, gas, oil, district heating, hydrogen), transport (aviation, rail, road, maritime), banking and financial market infrastructure, health and medical care, drinking water and wastewater, digital infrastructure, and public administration.

Important sectors include postal services, waste management, chemical manufacturing, food production, manufacturing of medical devices and motor vehicles, and digital providers.

The list above is not exhaustive. The full list of sectors can be found in the Cybersecurity Act and at mcf.se.

Size criteria: As a general rule, the law applies to medium-sized and large organizations, meaning organizations with at least 50 employees or a turnover and balance sheet total exceeding 10 million euros. Micro and small businesses are exempt unless they belong to a sector where they are considered particularly critical. The vast majority of government agencies, regions, and municipalities are covered regardless of size.

Do you belong to a covered sector, meet the size criteria, and operate in Sweden? You are likely subject to the law. The next step is to register your organization with the Swedish Civil Contingencies Agency (MCF).

Unsure whether your organization is covered? Consult a lawyer or contact the supervisory authority for your sector.

Read more: Cybersecurity for Municipalities and the Public Sector

‍

‍

The core requirements — 10 security measures

Article 21 of the NIS2 Directive lists 10 security measures. Everyone covered by the law must have them in place.

‍

1. Risk analysis and information system security

You must continuously identify, assess, and manage risks to your systems. This means having a clear picture of what assets you have, what threats exist, and how you prioritize protection. This work must be ongoing, not something you do once and put in a drawer.

‍

2. Incident handling

You must be able to detect, manage, and recover from security incidents. That requires clear roles and people who know what to do when something happens. A plan that has never been tested provides false reassurance. Practise your procedures.

‍

3. Business continuity

Backups, recovery plans, and crisis management must be in place. The goal is to keep operations running even when things go wrong. Map which systems are critical and what you depend on.

‍

4. Supply chain security

You are not only responsible for your own environment. Suppliers and subcontractors who deliver digital services to you are also your risk. Map your supply chain and set security requirements in contracts.

‍

5. Security in the acquisition, development, and maintenance of systems

Security must be built in from the start, not added after a system is already in production. This includes keeping systems patched, managing vulnerabilities, and having procedures for acting on new vulnerability information.

‍

6. Evaluation of security measures

You must be able to show that what you're doing actually works. That requires follow-up and measurement of your security work. Regular security testing, such as penetration testing, is a natural part of this.

‍

7. Cyber hygiene and training

Everyone in the organization must have enough knowledge not to be a vulnerability. Train your staff and build a culture where secure behaviors are the norm. Leadership must participate actively, not just rubber-stamp decisions.

‍

8. Cryptography and encryption

You must have procedures for how cryptography is used in the organization. This covers protection of data both at rest and in transit, as well as how cryptographic keys are managed.

‍

9. Access control and personnel security

Who has access to what must be governed by role and actual need. This includes procedures when staff join or leave, ongoing review of permissions, and management of IT assets.

‍

10. Multi-factor authentication and secured communications

Strong authentication methods must be used for access to critical systems, both externally and internally. Internal communications and emergency communications must be secured.

‍

Reporting obligations

NIS2 sets clear requirements for how and when you must report incidents. Reports are submitted to the supervisory authority for your sector.

Within 24 hours of becoming aware of a significant incident, an early warning must be submitted. A brief signal that something serious has occurred — nothing more is needed at this stage.

Within 72 hours, a more complete incident notification must be submitted. Here you describe what happened, your initial assessments, and what measures you have taken.

Within one month, a final report must be submitted with a complete analysis of the incident, its consequences, and how you have handled it.

What counts as a "significant" incident? An incident that causes or risks causing serious disruption to your service, or that affects other organizations or societal functions. Contact the supervisory authority for your sector if you are unsure.

Note that late or missing reports can lead to sanctions. You do not need to have suffered a serious attack to face fines — non-compliance with the reporting obligation is enough.

‍

Leadership accountability

One of the clearest changes in NIS2 compared to NIS1 is that leadership accountability is explicit. Cybersecurity can no longer be simply delegated to the IT department.

The board and senior management are responsible for approving and following up on the security measures the law requires. They must educate themselves on cybersecurity in order to fulfil that responsibility seriously. In the event of serious shortcomings, they can be held personally liable.

Sanctions are tied to global turnover. For essential entities, up to 10 million euros or 2 percent of global annual turnover. For important entities, up to 7 million euros or 1.4 percent. The higher of the two amounts applies.

Cybersecurity is no longer an IT matter with its own budget line. It is a leadership issue with legal and financial consequences.

‍

Getting started — an action plan

Full compliance takes time. Structures, procedures, and a security culture are not built in a week. But there is a logical order to work through.

Step 1: Confirm whether you are covered. Go through the list of included sectors. Check your size against the thresholds. Contact the supervisory authority for your sector if you are unsure. Register with the Swedish Civil Contingencies Agency once you have confirmed that the law applies to you.

Step 2: Conduct a gap analysis. Measure your current security level against the ten measures in Article 21. Identify where you have gaps. The foundations are often in place, but the systematics and documentation are missing.

Step 3: Draw up an action plan with named owners. Prioritize by risk and start with what delivers the greatest effect. Decide who is responsible for what and set realistic deadlines. Leadership must be involved — it is a legal requirement.

Step 4: Implement and document. Carry out the measures and document as you go. You must be able to show the supervisory authority that you are working systematically. Documentation is proof that the work is actually being done.

Step 5: Follow up continuously. NIS2 is an ongoing effort. Test your plans, update your risk analysis, and keep training current.

‍

How Cyloq can help

Cyloq works with offensive cybersecurity. We test your systems the same way an attacker would, giving you a concrete picture of where you are actually vulnerable, not just what your policy documents say.

Our services directly address several of the NIS2 requirements. Penetration testing and vulnerability scanning cover requirements 5 and 6 on vulnerability management and evaluation of security measures. Our incident response capability prepares you to meet requirement 2. And business continuity planning strengthens your operational continuity under requirement 3.

Want to know where you actually stand? We offer a NIS2 gap analysis with a clear current-state assessment and a prioritized list of actions.

Contact us

‍

This guide provides a fact-based overview of NIS2 and the Swedish Cybersecurity Act. It does not replace legal advice. Questions about whether your organization is covered by the law, or how specific requirements apply in your context, should be discussed with a lawyer.

A cyber incident can happen at any time. It could be ransomware encrypting your files in the middle of the night, a data breach that's been going on for weeks without anyone noticing, or a phishing attack that gave an attacker access to an admin account. What determines how bad it gets is rarely the nature of the attack, it's how quickly and methodically you respond.

That's what incident management is about.

What is incident management?

Incident management is the structured process for identifying, containing, investigating, and recovering from a security incident. It covers the technical work, external communications, and the legal aftermath.  

Many people confuse incident management with crisis management. Crisis management is broader and covers everything from natural disasters to PR crises. Incident management is specifically focused on IT security incidents and follows a well-defined process with clear roles and phases.  

A common misconception is that having an incident management plan on paper is enough. A plan that's never been tested is effectively useless during an active attack. Stress, time pressure, and unclear roles mean that untested documentation rarely gets followed. The plan has to be practiced, and the roles have to be second nature.

‍

The six phases of incident management

Established incident management frameworks divide the process into six phases. They look like a linear sequence, but in practice several of them overlap, especially during an active incident.

‍

Phase 1: Preparation

Everything starts before the incident happens. The preparation phase is about building the capacity to actually handle an incident. That includes defining roles and responsibilities, developing an incident management plan, establishing communication channels, and setting up the technical tools needed for logging and detection. Organizations that invest properly in preparation handle incidents faster, limit damage more effectively, and recover with fewer complications.

‍

Phase 2: Identification

Something seems off. Maybe a system is unusually slow, a user has logged in from an unexpected country, or an alert has triggered in your SIEM. The identification phase is about determining whether you're actually dealing with an incident, and if so, what happened, which systems are affected, and how serious it is. Inaccurate or delayed identification is one of the most common mistakes during incidents, and every hour of delay gives the attacker more room to operate.

‍

Phase 3: Containment

The goal is to stop the spread. That might mean isolating affected systems from the network, blocking specific IP addresses, disabling user accounts, or segmenting parts of the infrastructure. It's important to distinguish between short-term containment, quickly limiting the damage, and long-term containment, which means more sustainable measures while the investigation continues. Shutting down systems too early, before evidence has been secured, is a common mistake that can complicate the forensic investigation.

‍

Phase 4: Eradication

Once the spread is contained, the work of actually removing the threat begins. That can mean removing malware, closing backdoors, revoking compromised credentials, and patching the vulnerabilities the attacker exploited. The eradication phase often requires deep technical expertise and forensic analysis to make sure the attacker is no longer in the environment, hiding in a system you haven't looked at yet.

‍

Phase 5: Recovery

The systems are clean. Now it's about gradually bringing them back online and verifying that they're functioning correctly, with no remaining threats. Recovery usually happens in stages, the most critical systems are prioritized and each one is closely monitored before the next is brought up. It's not uncommon for the recovery phase to take weeks or months, especially after ransomware attacks where the backup strategy wasn't solid enough.

‍

Phase 6: Lessons Learned

The incident is handled, but the work isn't done. Two to four weeks after the incident is closed, a structured review takes place, a lessons learned session where the entire sequence of events is walked through. What worked? What didn't? What should we have caught earlier? The findings are used to update the incident management plan, improve detection capabilities, and make sure the same incident can't happen again.

‍

Roles and responsibilities during an incident

An incident is the wrong time to discuss who does what. Those roles need to be defined and practiced in advance.

The incident commander leads the response and makes decisions under pressure. This isn't necessarily the most technically skilled person, it's the person who can hold the big picture together, communicate up to leadership, and keep the work moving forward even when the situation is unclear.

The technical lead is responsible for the forensic investigation and technical actions: isolating systems, analyzing logs, and removing the threat. In a complex incident, multiple specialists may be needed with responsibility for different parts of the infrastructure.

The communications lead handles all external communication, to customers, vendors, and if necessary the media, as well as internal communication to employees. It's a role that requires good judgment and is often underestimated during active incidents.

Legal and compliance need to be involved early, especially if personal data may have been stolen. Reporting deadlines are tight, and the legal aftermath can be costly if it's mishandled from the start.

Leadership needs regular updates and is ultimately responsible for business-critical decisions, such as whether operations should be temporarily shut down or whether to proactively communicate to customers.

‍

Communication during an incident

Communication during an active incident is hard. There's a natural pull toward saying as little as possible to avoid alarm, but under-communication often causes more damage than transparency.

Internally, employees need to know what's happening, what they're expected to do, and what they shouldn't do. A common instruction is to not discuss the incident externally until the communications lead has approved it, to prevent inaccurate information from spreading.

Externally, you need to determine whether customers or vendors are affected and when they should be informed. Late communication that feels like a cover-up is often more damaging to trust than early communication that acknowledges what happened.

Regulatory reporting is not optional. For personal data breaches, you're required to notify IMY within 72 hours under GDPR. For incidents in organizations covered by NIS2, a preliminary report to the relevant supervisory authority is required within 24 hours, and a more complete report within 72 hours. CERT-SE is the national point of contact and can provide operational support during serious incidents.

Common mistakes during incidents

Many of the mistakes made during incidents are predictable. That means they can be prevented.

• Shutting down systems too early. It might seem logical to immediately shut down a compromised system, but it can destroy critical evidence and complicate the forensic investigation. Isolation is almost always better than a full shutdown.

• Communicating too late. Waiting to inform customers or regulators until you have "the full picture" often means missing deadlines and damaging trust more than necessary.

• Not having a tested backup strategy. It's not uncommon for organizations hit by ransomware to discover that their backups are either encrypted along with everything else, or were never tested for recovery.

• Not documenting in real time. During an active incident, it's easy to focus on the technical work and forget to keep a log. That makes both lessons learned and any legal proceedings significantly harder.

• Underestimating lateral movement. An attacker who's gotten into one system has often moved further into the network. Focusing only on the first compromised system can leave the threat sitting elsewhere in your environment.

• Resolving the incident without understanding the root cause. Cleaning up and restoring without identifying how the attacker got in means the door is still open.

When should you bring in outside help?

Not every incident requires external support, but in some situations getting the right expertise in quickly is critical.

Bring in outside help if the attack is still ongoing and you don't have the capacity to stop it, if your internal expertise isn't sufficient for a forensic investigation, if compliance requirements mean the investigation needs to be documented by an independent party, or if the scope of the incident is unknown.

Cyloq can be brought in on an emergency basis, even if you're not an existing customer. The first call is always free to assess the situation, and the contract and scope are defined in parallel with starting the response, so that nothing is delayed. The earlier you call, the more options you have.

‍

Read more: What to do when your company has been breached

Penetration test in brief

A penetration test, or pentest, is a controlled and authorized attack on your IT systems. A certified security specialist tries to get into your systems the same way a real attacker would, with the goal of finding weaknesses before anyone else does.

Companies conduct pentests to understand how well their security actually holds. Not just on paper, but in practice. It gives a concrete picture of what risks exist and what needs to be addressed, formulated in an actionable way. We are on top of this, Cyloq has conducted 500+ audits and identified 670+ critical vulnerabilities in Swedish companies and organizations.

‍

What types of penetration tests exist?

Which test is appropriate depends on what you want to protect. The most common tests look like this:

‍

Web Application Test

A web application test reviews the security of web-based services, login features, forms, and data feeds. It is suitable for those who have a customer-oriented web service or an internal web application that handles sensitive information.

‍

API Test

An API test focuses specifically on how your APIs handle authentication, access control, and data exposure. It is especially important for organizations that integrate services with external parties or expose APIs to customers and partners.

‍

External infrastructure test

An external infrastructure test examines everything visible against the internet, firewalls, servers, DNS and public services. It's a good first test for organizations that want to understand what an attacker actually sees and can exploit from the outside, without even having any prior knowledge of your environment.

‍

Internal network test

An internal network test simulates a scenario where an attacker has already gained access, for example through a successful phishing attempt or a compromised account. It is the right choice when you want to understand how far an internal attacker can actually move in the environment and what is accessible if the perimeter protection is deficient.

‍

Cloud test

A cloud test reviews configurations in Azure, AWS, or Google Cloud. It is especially suitable for those of you who have recently migrated to the cloud or who have built out your cloud services. Misconfigurations are one of the most common causes of data breaches in cloud environments and something traditional network tests rarely cover.

‍

Active Directory test

An Active Directory test examines how well your AD environment is protected against attacks such as privilege escalation, lateral movement, and Kerberoasting. This is relevant for virtually any organization running Windows-based environments, and especially important if you manage sensitive systems or have many users with different levels of permissions.

‍

Mobile App Test

A mobile app test examines the security of iOS and Android applications, how data is stored locally, how communication with the back-end occurs, and whether it is possible to manipulate the app's behavior in ways that were not intended. It suits anyone who has an app in production that handles user data or is connected to sensitive back-end systems.

Book an appointment with us and we will see which test suits you best.

‍

When should a company do a pentest?

There are a number of situations in which a pentest is particularly warranted:

• Ahead of a product launch. One of the best times to test, when you can still fix bargains before they reach your users.
• After a major system change. A migration to the cloud or a new integration almost always introduces new risks.
• In case of compliance requirements. NIS2, ISO 27001 and PCI-DSS impose requirements that security is actually tested and documented, and a pentest test is one of the most concrete ways to meet them.
• After a security incident. To understand how the attacker got in and ensure the road is closed.

For systems that handle sensitive data, pentest is recommended as routine, at least once a year. The threat picture is constantly changing, and a test conducted 18 months ago says nothing about how you stand today.

‍

White box, grey box and black box — what's the difference?

The three variants differ in how much information the tester receives about the system before the test begins, and the choice affects both depth and cost.

Black box means that the tester starts completely without prior knowledge, just like an external attacker. It gives a realistic picture of how difficult it actually is to get in from outside, but can miss deeper vulnerabilities that require more time and transparency to find.

White box gives the tester full access to source code, system documentation, and architecture. It allows for a thorough review and is a good fit when you want to maximize coverage, for example for a product launch or a major system shift.

Grey box is a combination of the two. The tester receives limited information, such as a login or a system overview, simulating an attacker with some visibility into the environment. It is often the most cost-effective option for established systems and provides good coverage without requiring as much time as a full white box test.

‍

How is a penetration test done?

The process follows a structured pattern regardless of the test in question:

It starts with a initial meeting where you and the test team define what should be tested, what systems are included and what is out of scope. Here you decide together the schedule, test method and rules of the engagement.

Thereafter charting the tester environment, collects information about exposed services, domains, and potential entry points, without yet attempting to enter.

Then follows a vulnerability analysis. Here, the entry points found are identified and evaluated. Incorrect settings, outdated software and logic flaws are mapped out and prioritized for the next step.

The Exploitation is what distinguishes a pentest from a vulnerability scan. The tester actively tries to exploit the vulnerabilities identified to verify whether they can actually be exploited in practice and how far an attack can go.

Everything is then documented in a reportage technical descriptions, severity ratings and concrete action proposals. The report is not raw data, but a basis you can actually work with.

In conclusion, one is held rapprochement where you go through the findings together with the team. You can discuss priorities and get your questions answered.

A typical test takes 1 to 4 weeks depending on the scope and type of test.

‍

What do you get in a pentest report?

A well-written pentest report is a working document, written for policymakers who want to understand the risk picture without having to delve into the technical details. The executive summary therefore provides a non-technical overview of the key discoveries.

Each vulnerability is classified with a severity rating, usually on the CVSS scale, from observations to critical vulnerabilities. Each finding includes a technical description of how the vulnerability works, where it is located and what it can be used for. In addition, reproduction steps are recorded that allow your team to verify and understand the findings in more detail.

The report concludes with concrete proposals for action and a prioritisation of what should be dealt with first. It should be possible to distribute the work internally immediately after the review.

Threats are moving faster. Is your security keeping up?

Cyber threats are evolving faster than ever. AI-driven attacks, zero-days exploited within hours, and supply chain intrusions are no longer things that might happen, they happen all the time.

According to the IBM Cost of a Data Breach Report 2025, the median cost of a data breach was 4.44 million USD. A large portion of these incidents originated from vulnerabilities that could have been prevented if the right protective measures had been in place. Among the most common entry points were phishing, attacks via suppliers and third parties, and compromised login credentials. At the same time, automation and AI accelerate both the speed and reach of attacks, resulting in more infections as more targets are hit in less time.

At Cyloq, we review hundreds of environments every year. In this guide, we summarize the seven most common security mistakes we see in the real world. Not only in code and configuration, but also in workflows, decision-making, and security culture.

Established frameworks like the OWASP lists are important reference points, especially within web application security, but they only capture part of the picture. In this guide, we combine these frameworks with insights from real-world attacks, tests, and operations. We highlight both technical and organizational weaknesses that appear again and again, and provide actionable advice and recommendations on how to prevent them.

1. Misconfigured systems and services

Misconfigurations are among the most underestimated risks to IT security. They appear in everything from applications and cloud services to network infrastructure and authentication solutions.

In the OWASP Top 10 2025 for web applications, this is listed as A02: Security Misconfiguration, but the problem extends far beyond the web. Incorrect settings, leftover functions, and open access points show up across all types of systems and environments. All it takes is a single incorrect setting, an unnecessarily open port, or a leftover debug function to open the door for an intrusion.

Common mistakes we see:

‍

• An open S3 bucket containing sensitive data, without authentication

• Publicly accessible test instances with weak passwords

• Admin panels not protected behind VPN or IP whitelists

• Incorrect permissions in cloud services – where “everyone” has read access to everything

The root cause is often small mistakes often caused by stress, unclear responsibilities, or complex environments where no one has full oversight.

Many systems are gradually built by different people, often with inconsistent documentation, which makes it difficult to maintain full visibility. This lack of consistency can easily result in oversights that leave the entire environment exposed.

What you can do:

‍

• Continuously scan for vulnerabilities‍

Use automated vulnerability scanning tools, both on code level and exposed infrastructure. Do this continuously, not just at release. Make sure to include test and staging environments in your scans.

• Define standard configurations

Define what a secure system configuration looks like in your organization. This makes deviations easier to detect and ensures security settings are actually followed in practice.

• Establish clear deployment and change management routines

All changes must be followed by testing. Automated CI/CD pipelines with integrated security controls reduce the risk that misconfigurations reach production.

• Review, audit, document

Secure configuration is not a one-time task. It requires ongoing work, clear ownership, and updated routines. Make sure to document not only what you do - but why you do it.

2. Insufficient network segmentation

Network segmentation is one of the most fundamental defense mechanisms in modern IT environments.

A flat network structure is like leaving all the doors of a building unlocked. If an attacker gains access through a single vulnerable point, for example, a user’s device or a minimally protected server, they can often move freely through the rest of the infrastructure. This is called lateral movement, and it is common in targeted attacks.

An attacker may gain initial access through an outdated external web interface and, within hours, obtain full access to internal HR systems, financial data, and customer information. All because segmentation was missing.

What you can do:

‍

• Separate sensitive environments from user networks

• Restrict communication between segments with firewalls and policies

• Allow only “need-to-know” access between systems

• Combine segmentation with Zero Trust principles

Segmentation doesn’t solve everything. But it can be the difference between a local incident and a full-scale breach. By restricting access, segmentation compensates for other weaknesses and buys you time to react.

3. Incident response that only exists on paper

Most organizations have some form of incident response plan. It sits in a folder on the intranet, was last updated a few years ago, and includes roles and processes that are no longer relevant. And it has never been tested in practice.

Only when a real incident occurs do the weaknesses become clear, such as:

‍

• Roles are unclear or unstaffed

• Logging doesn’t capture what is actually happening

• Communication paths are unclear

• Decisions are made too late - or not at all

The impact is that the attack is not stopped in time, and the consequences become enormous.

Imagine a ransomware attack starting late on a Friday. The IT department scrambles to contain it, but with limited visibility, they don’t realize how severe it is. The security manager isn’t looped in until Monday morning. By then, the damage is already done. The attack has spread, backups are encrypted, and multiple business-critical systems are offline.

To strengthen your incident response capabilities:

‍

• Simulate real scenarios – Run tabletop or red teaming exercises with real-time decisions

• Test your tech stack – Do your logs capture what you actually need?

• Clarify responsibilities – Who makes decisions, communicates, and handles recovery?

• Train the entire organization – Not everyone needs to know everything, but everyone should know their role

4. Overconfidence in internal competence

Another common mistake is relying too heavily on the internal security team. Even highly skilled teams risk becoming blind to their own environments. When you review the same codebase, the same configurations, and the same systems daily, it’s easy to miss subtle issues. And that's often where the real threats are hiding.

Many organizations also overestimate their security posture. Internal code reviews, automated tools, or checklist-based audits may create a sense of safety, but it is not always reality. We often hear: “We did our own review recently – it looked good.”
Yet during the first external test, we’ve uncovered critical vulnerabilities such as RCE (Remote Code Execution) or exposed sensitive data.

We recommend supplementing the internal team with an external security expert who is not part of the organization's processes and sees the environment with fresh eyes. This is often when the real risks are uncovered. And to maintain perspective over time, rotate between external testers, as they too can become blind to an environment.

Consider:

‍

• Complement internal reviews with external validation
  Internal insights are valuable, but outside perspective reveals what teams often miss.

• Schedule regular external penetration tests
  Frequent, real-world testing uncovers vulnerabilities before attackers do.

• Choose a skilled partner
  Not all auditors deliver the same value. Find experts who understand your risks.

External validation also builds trust among customers, investors, and the board by showing that your security has been practically tested and verified.

5. Weak authentication and access controls

Authentication is the first barrier an attacker must bypass. But if that barrier is weak or inconsistent, the strength of the rest of the infrastructure doesn’t matter. We still see shared accounts, plaintext passwords, MFA enabled but not required, or even default passwords on exposed services. But authentication (who can log in) is only half the story. Authorization (what they can do once logged in) is equally crucial.

OWASP classifies these under:

‍

• A07: Authentication Failures

• A01: Broken Access Control (one of the most critical and common vulnerabilities we find)

Common mistakes we see:

‍

• MFA configured but not enforced for all endpoints (A07)

• Missing protections against repeated login attempts, enabling credential stuffing and hybrid password spraying (A07)

• Improper session token handling logged in plaintext (A07)

• Users modifying API calls or URL parameters to access others’ data (A01)

• Poorly defined roles that allow regular users to gain admin access (A01)

These issues create an attack surface that can be exploited for long periods before being detected.

What you can do:

‍

• Implement centralized, standardized authentication (SAML, OIDC)

• Manually review permissions and access logic

• Require MFA everywhere

• Apply least privilege for users and integrations

• Enforce protections against brute-force attempts

• Ensure proper session management

• Monitor authentication flows in real time

6. Supply chain vulnerabilities

You may have full control over your own systems, but that doesn’t help if your suppliers don’t uphold the same standard. Modern systems rely heavily on third-party components: libraries, APIs, plugins, cloud services, SaaS platforms. Each integration is a potential entry point.

Supply chain attacks have skyrocketed. According to the 2025 DBIR, breaches involving a third party have doubled: from 15% in 2024 to 30% in 2025. Attackers often look for side doors. Third-party integrations frequently receive less scrutiny, despite holding access to critical systems or data.

Common mistakes we see:

‍

• External components without update or ownership checks

• Weak security clauses in contracts

• Lack of security requirements in procurement

• No follow-up on supplier security stance

OWASP defines this category as A03: Software Supply Chain Failures.

What you can do:

‍

• Demand strict requirements from vendors and third-party services – Define clear minimum requirements for security levels, patching policies, incident reporting, and role-based access.

• Regularly review software dependencies – Keep track of which components you use, and how they evolve over time.

• Maintain separate environments and access controls for different vendors – Isolate integrations so they cannot affect core systems in case of a compromise.

• Follow up with recurring reviews and security dialogues – Setting requirements during onboarding is not enough; continuous follow-up is mandatory.

• Implement Software Composition Analysis (SCA) – Use automated tools that flag vulnerable dependencies and license risks within the codebase.

7. Weak security culture

Cybersecurity starts with people, not firewalls. That is why the human factor is one of the most vulnerable points in most organizations. According to Verizon DBIR 2025, 60% of all breaches involved human error. A clicked phishing link, an unlocked workstation, or mishandled USB stick can trigger a chain reaction. Even the best technical defenses can be bypassed if users aren’t aware of how attacks work, or how their actions might open the door.

Security culture does not happen on its own. It requires long-term work. A single annual e-learning module is simply not enough.

What you can do:

‍

• Configure spam filters to stop phishing before it reaches inboxes

• Train continuously, not occasionally

• Run realistic simulations

• Put security on the internal agenda

• Build an environment where people report issues quickly

• Track behaviors and improve continuously

Fact box: What is OWASP Top 10?

OWASP (Open Worldwide Application Security Project) is a global nonprofit working to improve software security. One of its best-known resources is the OWASP Top 10, which lists the most common and critical vulnerabilities in web applications.

OWASP publishes several Top 10 lists (for APIs, cloud, mobile, etc.).  

About Cyloq

We have worked with everything from tech companies and government agencies to international enterprises and critical infrastructure. With more than 15 years of experience, we’ve developed a sixth sense for how attacks happen, how weaknesses arise, and where real risks hide.

We’re a partner you can trust, with the expertise to understand your reality and adapt our work to your industry’s specific requirements.

Ready to see if your systems are as secure as you think?

Now you know the mistakes that can undermine even the most experienced security teams. Knowledge goes a long way, but you also need to test your systems for real.

A penetration test is the most concrete way to identify vulnerabilities before someone else does. It shows exactly where the weaknesses are – and where to strengthen.

Cyloq performs advanced, manual tests from an attacker’s perspective. We map your attack surface, identify vulnerabilities, and show how far an attacker could get – and what you can do to stop it.

Our goal is not to confirm that everything looks fine. Our goal is to find what could bring you down, before someone else does. And if we can’t find anything – you can be confident no one else will either.

“We want them to find things, but of course we had strong confidence. We didn’t think they’d be able to do it in such a short time.”  -Tim, VX Fiber

‍

“We were pleasantly surprised. They found several issues that hadn’t been discovered in previous penetration tests or our bug bounty program. We were very happy with the results!” -Marcus, Stravito

Prevent weaknesses. Test for real.

This is how a penetration test with Cyloq works:

• Kickoff meeting: We define scope and goals together

• Attack phase: We test your environment thoroughly

• Ongoing reporting: Critical issues are reported immediately

• Delivery: You receive a clear, actionable report

When you’re ready to move from insight to action, you can contact us here.