# Penetration testing and vulnerability assessment | RootCore LLC

> Ethical hacking for websites, shops and servers — vulnerability assessment, configuration review, a detailed report with a fix order, and a retest afterwards.

Page: https://cyber-security.rootcr.com/en/penetration-testing/
Updated: 2026-08-20

---

# Penetration testing and vulnerability assessment

> **In short:** During a penetration test we try to reach your system with the same methods an attacker would — only with permission, documented, and with a write-up of how far we got. The result is a prioritised list: what is critical, what can wait, and what each fix is worth. After the fixes, we retest.

## What is the difference between a vulnerability assessment and a pentest?

| | Vulnerability assessment | Penetration test |
|---|---|---|
| What it does | Looks for known flaws, largely automated | Exploits what it finds and keeps going |
| What it shows | What *may* be vulnerable | How far someone can actually get |
| How long | Hours to a day | Days |
| When it is enough | Regular status checks | Before go-live, after an incident, for larger systems |

For most small and mid-sized companies the combination works best: regular assessments, plus a deeper test once a year or after a major change.

## What do we examine?

- **Web application:** login and session handling, permissions, forms, file upload, API endpoints, injection flaws (SQL injection, XSS), business logic errors.
- **Server:** open ports, outdated versions, weak cryptography, information leaking through error messages.
- **Configuration:** security headers, certificates, permissions, exposure of backups.
- **Access:** default and weak passwords, unnecessary accounts, forgotten developer interfaces.

## What do you get at the end?

A report you can read even if you are not a security engineer:

1. **Executive summary** — where you stand, what the biggest risk is, how much work the clean-up is.
2. **Findings by severity**, each with: what we found, how to reproduce it, what the consequence is, how to fix it.
3. **A fix order** — what needs doing today, what is this week, what is this quarter.
4. **A retest** after the fixes, confirming in writing that the hole is actually closed.

## How does it start?

Before testing we put in writing what may and may not be tested — target URLs, IP ranges, time window, excluded operations. On live systems, anything that creates load runs in an agreed window. The free assessment needs none of this: it is done from the outside, without load.

## Frequently asked questions

### Will testing harm my live system?

The overwhelming majority of the work is passive or low impact. Anything that may create load is flagged and scheduled in advance. We do not run data-modifying operations against live data; that happens only in a test environment or with explicit permission.

### How long does a test take?

A typical website or shop takes 3–7 working days, depending on the size of the system and the number of APIs. We give the exact figure after the assessment — guessing up front is not useful.

### Do I have to give you access?

Not for an external (black box) test. For finding authorisation flaws, however, test accounts for the different roles help — that is how it becomes visible whether an ordinary user can reach something they should not.

### What happens to the vulnerabilities you find?

They appear nowhere outside the report, and we do not pass them to third parties. The report is sent encrypted, and on request we delete every working copy once the fixes are confirmed.

### If you find something, do you fix it?

If you ask us to, yes — but it is not a condition. The report is written so that your own developer can work from it. If we do the fixing, the [server security](/en/server-security/) and [WAF](/en/waf-configuration/) work can run in the same engagement.