Skip to main content

Organisational Policies - Security Testing

The effective application of Chapter 10 - Security Testing requires the existence of formal organisational policies that define:

  • What to test, when to test and how to validate application security;
  • The minimum required levels of coverage and proportionality by criticality (L1–L2–L3);
  • Findings management, exceptions, revalidations and traceability mechanisms;
  • The periodic execution of offensive testing (PenTesting) as reinforcement and complementary validation of automated mechanisms.

📌 Fundamental note​

⚠️ Effective security validation does not depend on tools alone - it depends on clear policies that establish criteria, responsibilities and continuous control.

These policies:

  • Formalise the minimum validation requirements by application type and risk;
  • Define security-based release approval and rejection criteria;
  • Require traceability between findings, exceptions, decisions and releases;
  • Establish the use of manual offensive validation (PenTesting) as complementary reinforcement where applicable;
  • Facilitate external audits, regulatory compliance and continuous improvement.

🧩 This chapter executes and operationalises organisational policies relating to continuous validation and security testing.

🧾 Recommended policies​

Policy NameMandatory?ApplicationSummary of required content
Application Security Validation Policy✅ YesAll applications with continuous deliveryRequired test types (SAST, DAST, fuzzing), minimum levels by criticality, approved tools.
Security Findings Management Policy✅ YesAll products with an active scannerProcess for triage, classification, prioritisation, tracking, ownership and reporting of findings.
Policy on Exceptions to Identified Vulnerabilities✅ YesWhen a finding is not fixedTechnical justification, validity period, periodic review, compensating mitigation.
Offensive PenTesting Execution Policy⚠️ OptionalL2/L3 applications, external APIs, critical productsDefined periodicity (annual at L2/L3, with triggers), scope, methodology, objectives (black-box/grey-box), mandatory reporting and follow-up.
Security Test Coverage Policy⚠️ OptionalCritical applications (L2–L3)Definition of expected coverage metrics, targeted fuzzing, regression testing.
Policy on Integrating Testing with the Lifecycle⚠️ OptionalTeams with DevSecOps integrationDefinition of BDD criteria, integration with pipelines, PRs and release processes.
Test Revalidation and Observability Policy⚠️ OptionalEnvironments with audit requirementsRevalidation of findings, logging of tests, analysis of execution failures.
DAST and Fuzzing Policy⚠️ OptionalL2/L3 applications, public APIsAuthenticated DAST, fuzzing on critical endpoints, management of dynamic findings.
Secure Release Policy✅ YesAll applications with continuous deliveryRelease checklist, security-based go/no-go, documented risk acceptance.

📋 Suggested structure of each policy​

Each policy must include, at least:

  • Objective and scope (e.g. security validation by application type or context);
  • Mandatory criteria by criticality level (L1–L3);
  • Technical requirements by test type (e.g. permitted tools, formats, thresholds, scopes);
  • Roles and responsibilities (e.g. QA, AppSec, product, Dev team, Red Team or external team);
  • Format of required evidence (e.g. reports, logs, dashboards, issues, SBOM);
  • Exception, follow-up and periodic revalidation processes;
  • Policy review and improvement cycle.

✅ Final recommendations​

  • These policies must be approved jointly by the Security, Quality and Development areas;
  • They must be documented, accessible and integrated into the software lifecycle;
  • Their application must be auditable, based on objective evidence and aligned with automated pipelines and planned offensive testing;
  • The organisation's maturity in security validation depends not only on the execution of tests, but on the existence of formal and consistent criteria.

📌 Well-defined policies are the guarantee that tests - automated or manual - have a real, visible and continuous impact on the organisation's security.