Contact
Security

Penetration Testing and Red Team Services

Edilec runs authorized security testing for organizations that want to find weaknesses before attackers do. Every engagement is scoped in writing and signed off by the client before testing starts.

Request this service

Find the weaknesses before attackers do.

Authorized penetration testing and red team exercises for web and mobile apps, APIs, cloud, networks and identity, scoped in writing before any test starts.

Best fit

For organizations that hold sensitive data or money, are preparing a major release, or need independent evidence that their controls work.

Banks, payments and lending companies SaaS and e-commerce teams before a major release Organizations that need independent security evidence for customers or auditors
Penetration Testing

Security delivery path

01 Scoping

Scope document (targets, test windows, exclusions and emergency contacts)

02 Written authorization

Signed rules of engagement and authorization letter

03 Testing

Evidence log

04 Reporting

Report with severity-ranked findings and fix steps

05 Retesting

Retest results and a signed testing certificate (terms agreed in each contract)

What gets designed, built and prepared for real use.

01

Web applications and APIs

Authenticated and unauthenticated testing of web apps and REST or GraphQL APIs.

02

Mobile applications

Android and iOS apps and the APIs behind them.

03

Cloud environments

AWS, Azure, Google Cloud and private cloud setups, covering identities, storage, network exposure and logging.

04

Identity and access

SSO, MFA, roles, account recovery and privilege escalation paths.

05

External and internal networks

Internet-facing services, remote access, internal segments and directory permissions.

06

Red team exercises

Goal-based, multi-stage simulated attacks, including assumed-breach starts, mapped to MITRE ATT&CK.

Expand

Built for teams with real operating complexity.

Common capability areas Edilec can shape around the service, from planning details to delivery components.

Penetration testing services

Authorized testing of applications, APIs, cloud and networks, with findings ranked by severity and clear fix steps.

Red team assessment

Goal-based simulated attacks that test detection and response as well as prevention.

Banking and payments security testing

Internet and mobile banking, payment and transfer systems, lending platforms and internal bank networks.

Cloud penetration testing

AWS, Azure, Google Cloud and private cloud environments.

Phishing simulation

Social engineering tests on staff, run only with the client's written approval.

Secure code review

Focused review of high-risk code paths alongside application testing.

A delivery path that stays readable from scope to launch.

Scoping

Scope document (targets, test windows, exclusions and emergency contacts)

Written authorization

Signed rules of engagement and authorization letter

Testing

Evidence log

Reporting

Report with severity-ranked findings and fix steps

Retesting

Retest results and a signed testing certificate (terms agreed in each contract)

Safe testing rules

We test only systems the client owns or is authorized to have tested. We test nothing outside the signed authorization. We never run destructive attacks or ransomware, and never test safety-critical systems. Critical findings go to the client immediately, not at the end. Test data is stored encrypted and deleted at the end of the period agreed in each contract.

Standards and team

We follow the OWASP testing guides, PTES and NIST SP 800-115, choosing the method that fits each engagement. We rank findings with CVSS and map red team activity to MITRE ATT&CK.

Our security testing team of more than ten engineers holds certifications including OSCP, OSWE, OSEP, CEH, CISSP, CISM and CREST. Engagements are led by Krishnam Murarka, Founder and CEO.

Acceptance plan

Agree how the work will be checked.

Before delivery begins, Edilec and your team turn the selected scope into reviewable acceptance checks. Test data, environments, thresholds and sign-off owners are agreed for the project; these examples describe verification, not a fixed commitment outside that scope.

  1. Written authorization

    Confirm the signed rules of engagement and authorization letter cover every agreed target, test window and exclusion before testing starts.

  2. Reported findings

    Inspect each finding for a severity score, evidence, business impact and steps to fix it, and confirm critical issues reached the agreed contact immediately.

  3. Verified fixes

    Test fixed findings again on the agreed terms and record which are resolved and which remain open, each with an owner.

Track record

Our team has run client security testing since 2022, across more than 25 engagements for banks, payments and lending companies, SaaS, e-commerce, healthcare and logistics businesses. Clients are never named; each example below describes the client by sector and size. All testing used test accounts and synthetic data.

Mid-size retail bank (about 800 to 1,200 staff)

Penetration test, July to August 2026, six weeks.

Tested: internet banking, Android and iOS apps, customer APIs, sign-in and account recovery, statement downloads, beneficiary management and a customer-support portal. Core banking, ATM and payment-network infrastructure were out of scope.

Found: 18 issues (4 high, 9 medium, 5 low, none critical).

Main issue: missing server-side permission checks let one customer reach some of another customer's records, and beneficiary approval was not always tied to the exact details approved.

Outcome: ownership checks were added to the affected services and approvals were bound to the approved details. The retest confirmed 15 of 18 fixed, including all 4 high; the rest have owners and dates. No funds were moved.

Payments company (about 100 to 150 staff)

Penetration test, August to September 2026, five weeks.

Tested: merchant dashboard, payment and refund APIs, payment-provider notifications, transaction-status handling, reconciliation, API-key permissions and selected cloud access, using test merchants and provider sandboxes.

Found: 17 issues (4 high, 8 medium, 5 low, none critical).

Main issue: a repeated payment notification could credit a merchant twice, because a completed transaction was not reliably recognized as already processed.

Outcome: notifications are now authenticated, matched to the expected transaction and blocked from updating the ledger twice. The retest confirmed 15 of 17 fixed, including all high and medium issues. No live settlement or customer funds were involved.

B2B SaaS company (about 70 to 100 staff)

Penetration test with focused code review, July 2026, four weeks.

Tested: the multi-tenant web app, customer and admin APIs, workspace invitations, roles, single sign-on, API tokens, background export jobs and cloud file access, using separate test workspaces.

Found: 13 issues (3 high, 6 medium, 4 low, none critical).

Main issue: a background export job did not always keep one customer's data separate from another's.

Outcome: verified customer context now travels through every step of the export, and jobs without it are rejected, with regression tests added. The retest confirmed 12 of 13 fixed, including all high and medium issues.

Online retailer (about 250 to 400 staff)

Penetration test, September 2026, four weeks.

Tested: storefront, mobile APIs, checkout, order management, returns, store-credit refunds, promotional codes and customer-service permissions, including repeated, simultaneous and out-of-order requests.

Found: 16 issues (3 high, 8 medium, 5 low, none critical).

Main issue: two refund requests sent at the same moment could issue store credit twice for one return.

Outcome: refund checks and credit creation now run as one protected step, with unique refund references and limits tied to the original purchase. The retest confirmed 14 of 16 fixed, including all 3 high. Only test orders and test balances were used.

Lending company (about 300 to 500 staff)

Penetration test, July to August 2026, five weeks.

Tested: borrower onboarding, the loan-application portal, mobile APIs, document upload and download, the underwriting dashboard, staff roles and selected cloud storage permissions.

Found: 21 issues (5 high, 10 medium, 6 low, none critical).

Main issue: the loan-application API accepted changes to internal review fields that only authorized lending staff should be able to change.

Outcome: borrower data was separated from internal review data, the APIs now accept only permitted fields, and approval changes require the right staff role. The retest confirmed 18 of 21 fixed, including all 5 high. Only test applications and synthetic documents were used.

Health-tech company (about 150 to 250 staff)

Penetration test, August to September 2026, five weeks.

Tested: patient portal, clinician dashboard, mobile APIs, password recovery, sessions, appointment records, report downloads and selected cloud storage permissions, for patient, clinician and support roles. Medical devices and live treatment systems were out of scope.

Found: 14 issues (3 high, 7 medium, 4 low, none critical).

Main issue: password-recovery tokens were not reliably tied to the right account, which created an account-takeover risk.

Outcome: recovery tokens are now tied to one account, expire quickly and work only once, and affected sessions are revoked. The retest confirmed 13 of 14 fixed, including all high and medium issues. No real patient account or record was touched.

Logistics and warehousing company (about 1,000 to 1,500 staff)

Penetration test and goal-based red team exercise starting from a provided low-privilege vendor account, August to September 2026, seven weeks.

Tested: remote access, selected internal networks, directory permissions, vendor accounts, warehouse-support applications and security monitoring. Staff phishing, vehicles and operational machinery were out of scope.

Found: 24 distinct issues (6 high, 11 medium, 7 low, none critical).

Main issue: broad vendor access and weak network separation let a limited support account reach internal systems beyond its job.

Outcome: vendor access was limited to approved systems, extra privileges were removed, remote access got stronger sign-in, and monitoring now flags unexpected movement between network segments. The retest confirmed 20 of 24 fixed, including all 6 high, and the access path could no longer be reproduced.

Choose the right starting point.

Start here when this is the primary need. A discovery conversation may combine services after the boundaries are clear.

Start here

Choose Penetration Testing and Red Team Services

Choose penetration testing when you need an independent, authorized test of how your applications, cloud or network hold up against a real attacker.

Discuss this service
Alternative

Consider Cybersecurity, Identity and Access

Choose cybersecurity when identity, access and audit controls need to be designed or strengthened rather than tested.

View service
Alternative

Consider Quantum-Safe Security, PQC and QKD Readiness

Choose quantum-safe security when long-lived sensitive data and a post-quantum cryptography migration are the specific concern.

View service

Questions teams ask before this work begins.

Direct answers about scope, delivery and practical decisions for this service.

Do you test without written permission?

No. Every engagement starts with a signed rules-of-engagement document and an authorization letter from the system owner. We test nothing outside them.

Will testing disrupt our live systems?

We agree test windows, exclusions and emergency contacts in advance, never run destructive attacks, and stop and contact you if a test could affect operations.