Security testing of web, mobile, API and cloud systems, with fix support and retest
Application security testing covers web, mobile, API and cloud systems. Testers go through login, session handling, role permissions, source code and server configuration. You receive ranked findings with screenshots and reproduction steps, a remediation plan, fix support and a retest. Every item ends closed, open or accepted.
- Scope and rules of engagement are agreed in writing before any testing begins
- Findings are ranked by business impact, with evidence and reproduction steps
- Fix support and a retest record which items are closed
The work covers systems that businesses put in front of customers and staff. Examples are dealer portals, clinic systems holding patient records, school platforms with parent logins and logistics tracking APIs. Others are payment and document flows, and cloud accounts that grew one server at a time. Some reviews come before a launch. Others follow an enterprise buyer’s security questionnaire. A few begin with an application inherited from a vendor nobody can reach any more.
Where application exposure goes unnoticed
Records Visible Across Customer Accounts
A user edits an invoice number in the address bar, or opens an old emailed link, and another customer’s invoice, report or document appears. A complaint usually finds it, not a check. The code fix is often a single line, while the questions about who else did the same, and what they saw, take far longer to answer.
Broad Access Granted for Convenience
Logins are created as people join and rarely narrowed afterwards. An accounts assistant can delete records, a field executive can export the full customer list, and former staff still hold working credentials. Nobody reviews the list after go-live.
Files Open to Anyone With a Link
Identity scans, signed contracts, patient reports and database backups sit in a cloud bucket or shared drive that someone opened once for convenience. No login guards them and the link never expires. Nothing records who has downloaded them.
Security Raised Only by Customer Auditors
A large client or a bank sends a security questionnaire before signing, and the team must answer questions about encryption, access reviews and testing that were never written down. Onboarding stalls while someone reconstructs the answers from memory. The form waits.
Scan Reports Without Priorities
Someone runs a scanner and hands over several hundred lines in no order of importance. Developers dismiss some as false alarms and the rest have no owner, so the export sits in a folder untouched. The report exists. The risk is unchanged.
Passwords and Keys Shared in Chat
Database passwords, payment gateway keys and server logins live in a chat group, an email thread or a shared sheet. Some were passed to vendors who no longer work with the business. Rotation rarely follows a departure. Nobody can say which key serves which system.
Unowned Services Still Reachable Online
An old admin panel, a test copy of the website, a forgotten server or an open database port stays reachable from outside, left over from a finished project. It gets no patches and no attention. Automated attack scripts look for exactly this.
Nothing can be fixed until someone has looked. Not everything needs fixing at once either. The first step is an accurate picture of what is exposed, ordered by what each item would cost the business if it were abused.
Security findings written in business terms, with fixes and retest
Applications, APIs, cloud accounts and access controls are tested the way a person trying to misuse them would go about it. The results are written up with evidence and ranked by business impact. We support the fixes. Then the tests are rerun, so closure sits on record.
Manual Testing Alongside Tooling
Scanners catch known patterns. The rest needs a person working through the real screens and roles. One user opens another user’s records, a discount changes on its way to the server, or a clerk role can approve payments. Those are the gaps tooling misses.
Findings Ranked by Business Impact
Each finding is written twice. One version tells the developer which endpoint, parameter or setting is at fault. The other tells the owner what the flaw means for customers, money or legal duties, and that second version sets the order of work.
Remediation and Retest Included
Support continues through remediation, either by advising the client’s developers or by making the changes directly, and the specific findings are then retested. The client keeps the evidence of what was closed, plus a written note of anything knowingly accepted.
What changes after a security review
Focus on business value before discussing technology.
A Risk Register With Owners
One register lists every finding by business impact, with an owner and a next action beside each. It replaces a raw scanner export.
Permissions Matched to Job Roles
Roles, permissions and admin rights are reviewed and narrowed, and accounts belonging to former staff and vendors are listed for removal. Whoever manages access also receives a short method for repeating the review every quarter.
Fixed Findings Verified Against Evidence
High and medium items are rerun against the original reproduction steps, and closure is recorded from the test output. A developer’s message saying it is done does not count.
Documents for Customer Questionnaires
A dated report, a remediation record and a retest result can go to an enterprise client, a bank or an auditor. Together they show what was tested and what changed afterwards.
Testing Inside an Agreed Window
Weaknesses in a new portal or app are hunted inside a test window the client approves, by an engaged team, before real users depend on the system. Launch day is not the first test.
Security Checks in the Build Pipeline
Dependency, secret and configuration checks can be added to the build pipeline, so new code is inspected as it ships. Any periodic manual review sits alongside them.
What cybersecurity and application security includes
Everything required from operational discovery to production deployment and long-term maintenance.
Security Consulting and Risk Review
A working session on what the business holds, who touches it and where the exposure sits. It ends in a plan that finance can budget. It is not a generic checklist.
Web Application Security Assessment
A portal, dashboard or website is tested across login, sessions, roles, payments, forms, file uploads and reports, using real user journeys and every role the system defines.
Mobile Application Security Assessment
Android and iOS builds are examined for data stored on the phone, intercepted traffic, API keys shipped inside the package, and screens or actions reachable outside the intended flow.
API Security Testing
APIs are tested directly, covering authentication, token handling, record-level permissions, bulk data pulls, rate limits and error responses. The app screen is never the only way in.
Vulnerability Assessment and Penetration Testing
A structured test (VAPT) pairs automated coverage with manual exploitation attempts inside an agreed scope. Each result arrives as a finding with reproduction steps and evidence.
Secure Code Review
A read through the code that handles authentication, permissions, payments, uploads and database queries. It finds flaws that stay hidden from outside until the wrong input arrives.
Authentication and Permission Audit
Every role, admin account and integration user is listed and compared with what that job needs. Password rules, multi-factor prompts and session lifetimes are reviewed at the same sitting.
Cloud and Server Security Review
AWS, Azure, Google Cloud or your own servers are checked for open ports and storage buckets, over-permissive roles and keys, and missing patches. Unencrypted volumes and backups that were never test-restored are flagged too.
Database and Data-Store Security
The review covers who can reach the database and from which network, how connection credentials are held, what is encrypted and how backups are protected. It also asks whether sensitive columns can be masked for read-only staff.
Secrets, Keys and Pipeline Security Checks
Keys move out of code, chats and shared sheets into a controlled vault, scoped to the minimum permission, with a rotation step for every staff departure. Dependency, secret and configuration scanning can join the build and release process, so a stray key is caught during the change itself.
Monitoring and Incident-Response Support
Logging and alerting are set up so an unusual login, a mass download or a privilege change raises a flag. A written response plan exists. Support is on hand when an incident occurs.
Data-Privacy and Standards Readiness
A review of what personal data is collected, where it travels and how long it stays. The technical work feeds an ISO 27001, SOC 2 or privacy-law effort that the client’s own auditor then assesses.
Where a security review is used
Real-world business processes we configure and automate.
Distributor Portal With Dealer Pricing
A distributor is about to open a portal where dealers see their own rates, credit limits and order history. A pre-launch review checks that one dealer cannot read another dealer’s pricing by editing an ID. It also checks that discounts cannot be altered between browser and server, and that the login copes with shared counter devices.
Diagnostics Chain Sending Report Links
A diagnostics chain sends report links by SMS and WhatsApp. Testing may show that a link opens without a login, never expires and follows a guessable pattern. The download is then reworked to demand a verified identifier, expire links and log each access. Report retention is reviewed too.
Manufacturer After a Cloud Migration
A manufacturer moves its ERP and shop-floor dashboards to the cloud. The quickest route left open access rules, one shared administrator key and a database reachable from the internet. A configuration review closes these gaps, splits access by role, moves keys into a vault and turns on backups and alerts. Plant hours set the schedule.
Coaching Institute With Parent and Student Logins
A coaching institute runs a platform holding student marks, attendance and parent phone numbers, and every staff member logs in as administrator. The audit brings in role-based access, removes accounts of teachers who have left, adds multi-factor for administrators, and stops a student account from opening another batch’s records.
Logistics Operator With a Shared API Key
A transport operator gives customers an API to track consignments, secured by a single key shared across all of them. Testing may show that one customer can query another’s consignment numbers. The fix moves to per-customer credentials, record-level checks and rate limits. No shared key remains.
Advisory Firm Taking Over a Client Portal
An advisory firm takes over a client portal from a developer who has stopped replying. Nobody knows what is exposed, what the old admin panel does or who holds the keys. A takeover review inventories what is running, closes forgotten staging sites and rotates credentials. A prioritised list comes before any new work.
Is This Service Right for Your Business?
We partner with established businesses that have outgrown manual processes and want reliable systems.
Businesses Launching a Customer-Facing Application
Companies opening a portal, app or online store where customers, dealers or patients log in and must see only their own records. Access flaws are caught before the first user arrives.
Companies Holding Personal or Financial Data
Clinics, laboratories, schools, lenders, insurance intermediaries and service firms that hold identity documents, health records, marks, contracts or payment details on behalf of other people.
Suppliers Answering Customer Security Questionnaires
Businesses whose enterprise clients, banks or partners send a security questionnaire before onboarding. They need test results and dated documents to answer it truthfully, not a promise.
Teams That Have Recently Moved to the Cloud
Organisations whose servers, storage and databases were migrated under a deadline, often with access rules left wide open so the cutover could finish.
Owners of Software Inherited From Another Vendor
Companies running an application built by a developer who is no longer available. It is unclear what is exposed, which credentials are live or what the old admin screens can still do.
When a Full Assessment Is Not the First Step
If an application changes every week and has no real users yet, the assessment should wait until the build settles. A report on rewritten code is wasted. Where the basics are missing, they come first. That means multi-factor authentication, removal of accounts of people who have left, no shared admin login, and backups that actually restore. A brochure website with no login and no customer data rarely needs a full VAPT, and we say so.
Enterprise Capabilities in Plain Business Terms
Authentication and Session Testing
Login, password reset, one-time-password flows, session expiry and multi-factor behaviour are tested, including routes that skip the intended step.
Record-Level Access Checks
Systematic attempts to open another user’s order, invoice, report or document by changing identifiers, a common cause of data exposure.
Input and Injection Testing
Forms, search boxes, filters and API fields are probed for SQL injection, script execution and business logic that unexpected input can bend.
File Upload and Document Access
Checks cover which file types can be uploaded and where they are stored. They also cover whether files can be executed, and whether a document URL still opens for someone who is not logged in.
API Keys, Tokens and Rate Limits
Token issue and expiry, permission scope, replay of old tokens, and whether bulk extraction is throttled.
Mobile Storage and Traffic Review
Data left on the handset, keys shipped in the build and certificate handling are reviewed. Traffic is tested to see whether it can be read or altered in transit.
Cloud Configuration Review
Storage exposure, network rules, over-broad roles, unused access keys, encryption settings and audit logging are reviewed across the cloud account.
Server and Network Exposure Mapping
A list of everything reachable from outside the office, including forgotten test sites, admin panels and open database ports.
Database Access and Encryption
Connection permissions, credential handling, encryption at rest and in transit, backup protection and masking for sensitive fields.
Secret and Credential Scanning
Repositories, configuration files and pipelines are searched for keys and passwords committed by mistake. A rotation plan covers each hit.
Logging and Alerting Review
The review asks whether an unusual login, a mass download or a privilege change leaves a trace, reaches a named person, and can be reconstructed afterwards.
Retest and Closure Evidence
Each fixed finding is rerun against its original steps. The result is recorded so closure can be shown.
Our Structured 6-Step Delivery Process
A transparent path from your first conversation to a reliable production release.
- 01
Scoping and Rules of Engagement
The scope, the type of testing allowed and the timing are agreed in writing. The client supplies the applications, URLs, APIs and cloud accounts to be covered, plus written authorisation from each owner. A test window and one escalation contact who can be reached during testing are also needed.
- 02
Access, Test Accounts and Environment Setup
The team decides whether to work on a staging copy or on a live system with limits, and how each system is reached. The client provides a test account for every role and a staging environment or recent copy where one exists. Reviewer access to the cloud console is read-only, and any hosting provider approval is needed too. Source code access is needed only for a code review.
- 03
Assessment and Manual Testing
Reachable systems are mapped and tooling is run for coverage. Testers then work by hand through each role, covering authentication, permissions, data access, payments, uploads, APIs and configuration. Anything that could disturb live data is cleared with the client’s contact first. A log records what was tested and when.
- 04
Findings, Severity and Business Impact
The findings register lists what was found, the evidence, reproduction steps, a severity and a plain explanation of the business meaning. One walkthrough session takes the client’s team through it. The client needs a person who can decide priority and sign off any decision to accept an item.
- 05
Remediation Planning and Fix Support
Each item gets an owner, an approach and a place in the sequence, with the highest-risk work first. The client’s developers can make the changes with guidance and review, or we make them, in which case the client provides a handover of code and environments.
- 06
Retest, Evidence and Ongoing Checks
Fixed findings are retested against the original steps, and a retest report shows what is closed, what remains and what was accepted. The security baseline is handed over, and the people who watch alerts and manage access are trained. Periodic reviews or pipeline checks can follow. The client provides a change window and a named owner for the baseline.
What You Receive Upon Project Completion
Everything required to run, maintain, and expand your software without vendor lock-in.
Connects With the Systems You Already Rely On
We build bridges between your software so you don't have to replace functional existing tools.
Cloud, Hosting and Network Edge
- AWS
- Microsoft Azure
- Google Cloud
- DigitalOcean
- On-premise and colocated servers
- Cloudflare and WAF rules
- Load balancers, VPN and bastion access
Identity and Access
- Google Workspace
- Microsoft 365 and Entra ID
- Firebase Authentication
- Auth0
- Custom login systems
Code and Delivery
- GitHub
- GitLab
- Bitbucket
- GitHub Actions
- Jenkins
Application Stacks Reviewed
- Laravel and PHP
- Node.js
- Python and Django
- .NET
- Android and iOS apps
- WordPress
Sensitive Data Points
- Payment gateways
- KYC and document storage
- WhatsApp Business API
- Email and SMS providers
Selected for Reliability, Speed, and Longevity
Technology chosen to match your operational scale and long-term maintainability.
Assessment Tooling
Mobile Assessment Tooling
Code and Dependency Scanning
Cloud and Infrastructure Review
Reference Standards Used
Why Business Owners Choose GullySystem
Manual Testing as Well as Scanning
Automated coverage is only the starting point. The issues that hurt a small business come from working through the screens by hand. One customer reaches another’s records, a role does more than intended, or a value changes on its way to the server.
Findings Written for Two Readers
Each finding carries the technical description a developer needs and the business consequence an owner needs, side by side. Together they settle what to fix now and what can wait.
Fix Support From a Software Team
GullySystem is a software team as well as a reviewer, so remediation can go beyond advice. Where the client’s team makes the changes, we review them. Where the client prefers, we write the fix and hand the code back.
Retest as Part of the Engagement
A report is only half the work. Fixed items are rerun against the original evidence, and closure is written into a retest report.
Testing Planned Around Business Hours
Scope, timing and intensity are agreed in writing. Staging copies are preferred, work on live systems is throttled, and anything that could disturb real data or customers is cleared with the client’s contact first.
Clear Limits on What an Assessment Proves
No assessment can prove that an application is free of vulnerabilities. The report states what was tested, what was left out and what residual risk remains.
Flexible Engagement Options
Choose an engagement model that matches your operational scope, budget, and timeline.
Pre-Launch Security Review
A focused assessment of a new application, portal or app before go-live, timed so that findings can be fixed inside the launch plan.
Fixed-Scope Assessment
A one-time VAPT of an agreed set of applications, APIs and cloud accounts, priced against the scope document and delivered as a findings register with a remediation plan.
Assess, Fix and Retest
The assessment, the remediation work and the retest run as one engagement. It suits teams with no spare developer time to act on a report.
Ongoing Security Support
Periodic reassessment, access reviews, pipeline checks, patch and dependency monitoring, and response support, for businesses that ship changes through the year.
Frequently Asked Questions
Straightforward answers to the questions owners ask before getting started.
Is this a formal VAPT, or just an automated scan?
Yes, it is a formal vulnerability assessment and penetration test within an agreed scope. Automated tooling gives breadth. A person then works through the application by hand across every role, trying what a scanner cannot judge. That includes reaching another customer’s records, bypassing an approval or altering a value on the way to the server. You receive a scope document, a findings register with severity, evidence and reproduction steps, and a retest report.
Who actually performs the assessment?
Engineers who do security work, supported by penetration-testing specialists engaged for scopes that need them. The proposal names who does the work and what each person covers. Where GullySystem built the application, someone other than the code’s author reviews it.
Will testing disturb our live application or our customers?
The rules of engagement settle that, and they are agreed before testing. Where a staging environment or recent copy exists, testing happens there. On a live system, activity is throttled, destructive actions are avoided, intensive work runs outside busy hours and an escalation contact stays reachable. Real data, orders and customers are protected by confirming first. A log records what was run and when.
Do you help fix the findings, or only report them?
Yes, we help fix them. After the walkthrough, each finding gets an owner, an approach and a place in the sequence. The client’s developers can make the changes with guidance and code review, or we make them where the client has no capacity. Either way, the outcome is a list of items marked closed.
Is a retest included, and what evidence do we get?
Yes. A retest of the findings from the original assessment is included, run within the window agreed in the proposal. The original reproduction steps are rerun, the outcome is logged for each item, and the retest report shows what is closed, what is open and what has been accepted. Each risk the client chooses to live with is logged with its justification and the approver’s name, so nobody has to guess later why it stayed open.
Can you certify us for ISO 27001, SOC 2 or a privacy law?
No. An accredited certification body or an independent auditor issues certificates, not the vendor doing the technical work. A privacy law is a legal duty, not a certificate. We cover the technology side that such an effort rests on. That means access control and logging, encryption, secure development practice, testing records, data-retention and consent handling, and evidence for the auditor. We work alongside the client’s consultant or auditor.
Can you test an application another vendor built, and do you need the source code?
Yes, and source code is optional. A black-box assessment tests the running application, APIs and infrastructure from outside using test accounts, which is how software from an unavailable vendor is handled. Source code allows a deeper secure code review of authentication, permissions, payments and queries. Without it, the report says what that scope cannot cover.
Do you review our cloud, servers, databases and user permissions as well?
Yes. The review covers cloud storage exposure, network rules, roles and keys, patch levels, encryption, backup protection and logging, plus database connection permissions and how credentials are stored. Separately, every user, admin and integration account is listed and compared with what that job needs. This often turns up logins belonging to people or vendors who have left.
How do you protect our data, and who owns the findings?
The client owns everything produced, including the report, findings register, evidence and the source code of any fixes we write. Repository access stays in the client’s name. A signed NDA covers confidentiality before scoping begins. During testing we prefer test data over real records, use accounts the client creates, keep evidence to the minimum needed and mask personal data in screenshots. Reports travel over a controlled channel. Working copies are deleted on a schedule the client sets, and credentials issued to us can be revoked at any time.
What drives the cost of a security assessment?
It depends on scope and depth. A flat fee per application does not work. The drivers are the applications, APIs, environments and cloud accounts in scope, and the user roles each one needs tested. Mobile builds, a source-code review beside black-box testing, the amount of infrastructure, and whether we carry out the fixes or only advise all move the figure. Ongoing arrangements are priced differently from a one-time assessment. An itemised proposal follows scoping, split so lower-priority areas can be deferred.
What decides how long the work takes?
It depends mainly on access and scope, not on the testing itself. The drivers are how soon test accounts for every role and reviewer access to the cloud console are issued, and whether a staging environment exists. Others are the number of roles, the size of the application, whether code review and mobile builds are covered, and how fast developers turn findings around. The retest can only follow the fixes. Scoping turns these inputs into a dated schedule.
What do you need from us, and will you train and support our team afterwards?
To start we need four things. The first is the list of systems in scope, with written authorisation from their owners. The others are test accounts covering every role, an agreed test window with one escalation contact, and a person who can decide priority. Afterwards we train developers on the specific mistakes found in their own code. Whoever manages access learns to run a quarterly review and receives a short runbook on alerts. Ongoing support covers periodic reassessment, patch and dependency monitoring and pipeline checks.
Is a security assessment something we need right now, or should we wait?
The application’s current condition decides it. If it changes every week and has no real users yet, assessing a build about to be rewritten is effort spent twice. If the basics are missing, do those first. They are multi-factor authentication, removal of accounts of people who have left, an end to the shared admin login, and a test that backups restore. A simple brochure site with no login and no customer data rarely needs a full VAPT. Timing is right when customer data is exposed, credentials sit in chat threads or a bank’s security questionnaire is pending.
Read before you decide.
Practical notes on the questions this service raises, not product marketing.
How to Audit User Roles and Software Permissions
A practical process for reviewing who has access to what across your business systems, and fixing what's drifted since the last review.
Application Security Checklist for SMBs
A working application security checklist for small businesses: what to inventory, review, test and assign, in order, with a status and owner for each.
How Role-Based Access Protects Business Data
How role-based access control limits who sees customer, finance and staff records, and how to design, approve, audit and test it in practice.
Common Security Vulnerabilities in Business Applications
A defensive, non-technical look at the vulnerability categories that consistently affect business applications, and how SMBs can prioritise fixes.
Let’s Build the Right Software for Your Business
Tell us about your current operational challenge, spreadsheet bottleneck, or software requirement. An experienced engineer will review your workflow and reply within one business day.
- No obligation consultation
- Senior engineer reviews your brief
- Your operational details stay 100% confidential
Start with your requirements
Seven short steps that tell us what you need. An engineer reads them before getting in touch.
Share your requirementsRelated Practices & Services
QA and Software Testing
Functional, regression and release testing proves the software works correctly. Security testing proves it cannot be misused. The two run side by side.
Cloud and Managed Infrastructure
Set up, hardening and management of the cloud accounts and servers your applications run on, including backups, access and monitoring.
DevOps, Deployment and Reliability
Build and release pipelines where dependency, secret and configuration checks run on every change instead of once a year, so a leaked key is caught in the commit.
Software Maintenance, Support and Rescue
Ongoing patching, dependency upgrades and fixes for an application you have inherited or that no longer has a development team behind it.