System Security Acceptance Testing (SSAT)

System Security Acceptance Testing (SSAT) is the last security check before a new or upgraded system goes live. An independent team confirms that the finished system meets the security requirements agreed at the start of the project. The system owner can then approve the launch, or hold it back, based on test results.

It works much like a building inspection before opening day. Every control is checked in place, with all the parts connected, before real users and real attackers arrive.

When is SSAT needed?

SSAT is usually requested when a bank, government agency, telco or large enterprise is launching a new core system, digital channel or vendor platform, or finishing a major upgrade. Often it is a formal requirement. A procurement contract may say the vendor’s system must pass an independent security acceptance test, or internal policy may demand security sign-off before launch.

SSAT and a penetration test have different purposes. A penetration test asks “how could someone break in?”. SSAT asks “does this system meet every security requirement we set, yes or no?”. In practice, SSAT often uses penetration testing as one of its methods.

What good requirements look like

Acceptance criteria need to be specific enough to pass or fail. For example: “all sensitive data is encrypted when stored, using AES-256”, or “the application resists the common attack types in the OWASP Top 10”. They come from your security policy, risk assessment, threat model and any regulation that applies, such as GDPR, HIPAA or PCI DSS.

We test them against recognized standards: OWASP ASVS and OWASP WSTG for applications, OWASP MASVS for mobile apps, CIS Benchmarks for server and database settings, and NIST SP 800-115 for technical testing. Where useful, results are mapped to ISO/IEC 27001:2022, SOC 2 and PCI DSS.

Areas we usually test

Each requirement becomes one or more test cases, with inputs, an expected result and a pass or fail rule. The areas that come up most often:

  • Login, including wrong passwords, password rules and multi-factor authentication.
  • Access rights, meaning whether a user can reach functions or data outside their role.
  • Input handling, tested with injection and data manipulation attacks.
  • Encryption of data in transit and at rest, and how the keys are managed.
  • Sessions, including hijacking, fixation and automatic timeout.
  • Audit logs, checking that security events are recorded, protected and available for monitoring.
  • Hardening of servers, databases and middleware against CIS Benchmarks.
  • Resilience under heavy load or denial-of-service conditions, where this is in scope.

From first test to sign-off

Testing takes place in an environment that mirrors production as closely as possible. We combine vulnerability scanning, penetration testing, manual checks for logic flaws and configuration review.

Every gap between the system and its acceptance criteria is written up with the affected component, a severity rating based on CVSS and supporting evidence. The project team fixes the issues and we retest, confirming each fix works and has not broken something else. The cycle repeats until the criteria are met, or until the owner formally accepts any remaining risk.

The final report ends with a clear recommendation: go live, or not yet.

The documents you keep

  • A test plan and a traceability matrix linking each requirement to its test cases.
  • A findings report with severity, evidence and fix guidance.
  • Verification results for every fixed finding.
  • A final acceptance statement listing the requirements met, any open risks and advice for ongoing monitoring.

These documents also show regulators, auditors and customers that due diligence was done. And a problem found before launch is almost always cheaper and less disruptive to fix than one found in production.

Request an SSAT proposal to plan the security sign-off for your next launch.