Scope, authorize, test, report, retest.
Every EK Securities engagement follows the same five steps, whatever is being tested. Each step produces something in writing.
How does an EK Securities engagement run?
In five steps. We agree a written scope, the system owner signs an authorization, we test by hand with tools in support, we deliver a report with evidence and a fix for each finding, and we retest every fix and update the report. Each step produces something in writing.
Scope
We agree what is in and out: hosts, apps, roles, test accounts, environments and the hours testing may run.
out: written scope
Authorize
The system owner signs a written authorization before any test traffic is sent. No signature, no testing.
out: signed authorization
Test
Manual testing backed by tools. Every finding is confirmed by hand. A critical issue is raised as soon as it is confirmed, not saved for the report.
out: findings confirmed by hand
Report
Each finding with severity, where it is, the evidence, the impact and a fix your developers can apply.
out: report with evidence and a fix each
Retest
Once you have fixed the findings, we test them again and update the report to show what was closed.
out: report updated: closed or still open
1. Scope
A short call, then a written scope. It lists the hosts, applications, API routes and user roles in scope, what is out of scope, which environment we test, the hours testing may run, and the test accounts you will create for us.
We ask about anything fragile up front: a payment gateway in live mode, a server that cannot take a scan, a third-party service you do not own. Systems you do not own or control are out of scope unless their owner authorizes the test too.
2. Authorization
Before any test traffic, the system owner signs a written authorization that names the targets, the dates and the people allowed to test. If the systems are hosted by a provider whose terms require notice, you give that notice.
This is what separates a security test from an attack, and it protects you and us. No signature, no testing.
3. Testing
Testing is manual work supported by tools. Scanners find candidates; a person confirms each finding by reproducing it and records the request, response or configuration that proves it.
We do not run denial-of-service tests, do not change or delete your data beyond the test accounts, and stop to call you if something looks like it could affect live users. A critical finding is reported to you as soon as it is confirmed.
4. Report
The report opens with a plain summary for management: what was tested, what was found and what to fix first. Then each finding with its severity, where it is, the evidence, the impact and a concrete fix.
Findings are mapped to the OWASP Top 10, OWASP API Security Top 10 or OWASP MASVS where they apply, so they line up with what auditors and customers ask about.
5. Retest
When your team has applied the fixes, we repeat the original tests against them and update the report to mark each finding closed or still open. The updated report is the one you can show a customer or auditor.
Tell us what you want tested.
A short call, then a signed scope. No testing before that.