This post explains how to map technical controls—specifically SAST, DAST, and WAF—to documented requirements for external web applications to satisfy Essential Cybersecurity Controls (ECC – 2 : 2024) Control 2-15-1 under the Compliance Framework, with actionable steps, examples for a small business, and artefacts you should produce for an audit.
Why mapping controls to documented requirements is required
Control 2-15-1 expects organizations to demonstrate that technical protections for external web apps are intentional, repeatable, and auditable. Rather than simply deploying tools, compliance requires documented requirements and evidence that each tool addresses a specific requirement (for example: input validation, authentication hardening, vulnerability detection, and runtime protection). Mapping links requirement → control → tool → evidence, which lets auditors and internal reviewers verify coverage and residual risk.
Practical approach: build a Control Mapping Matrix
Create a simple Control Mapping Matrix in your Compliance Framework repository (spreadsheet or CSV). Columns should include: Requirement ID (ECC 2-15-1 sub-requirement or your internal policy clause), Risk/Objective, Responsible Owner, Control Type (SAST / DAST / WAF), Tool Name and Version, Configuration Summary, Scan/Rule Frequency, Acceptance Criteria, Evidence Location (scan reports, tickets, change logs), and Remediation SLA. This single artifact is the canonical mapping auditors will check.
Example mapping entries (real-world, small business)
Example A: Requirement = "Prevent injection and XSS in external web app" → Control Type = SAST + DAST + WAF. SAST tool (Semgrep v1.x) configured in CI to run on pull requests with rule set for SQLi and XSS; acceptance = < 5 high findings on merge, otherwise fail build and create JIRA ticket. DAST (OWASP ZAP) runs weekly against staging with authenticated scans; acceptance = no high/critical exploitable findings in production release candidate. WAF (managed Cloud WAF with OWASP CRS + custom rules) blocks known SQLi payloads and rate-limits suspicious input; logging forwarded to SIEM for 90 days. Evidence: CI logs, ZAP report PDF, WAF rule change log and SIEM alerts.
Implementation details: SAST, DAST, WAF—how to configure for compliance
SAST: integrate into CI/CD (GitHub Actions, GitLab CI, Jenkins). Use baseline rule sets first (e.g., Semgrep, SonarQube) then tune to reduce false positives. Configure pull-request gates for high/critical severity findings and auto-create remediation tickets for medium/low. Document the rule set, rule version, and threshold in the mapping matrix and retain historic reports for at least the retention period required by your Compliance Framework.
DAST: perform authenticated and unauthenticated scans against a staging environment that closely mirrors production. Schedule frequent scans (weekly or every sprint) and full regression scans before major releases. Configure ZAP or commercial scanners to produce reproducible attack traces and evidence (HTTP request/response pairs). Document scan scope, authentication methods, and exclusions (e.g., load-sensitive endpoints) to show auditors you manage test safety and representativeness.
WAF: choose based on scale and skillset—open-source ModSecurity (with front-end proxy) or cloud-managed WAF (Cloudflare, AWS WAF, Azure Front Door) for small businesses. Start in detection mode to gather baseline traffic and tune rules to reduce false positives; then move to blocking. Maintain a change log for rule modifications, document the CRS version, custom rules with justification, and retention of WAF logs. Ensure WAF exceptions have documented risk acceptance and owner approval.
Operationalize remediation and evidence collection
Map each finding to a ticketing workflow with owners and SLAs (e.g., Critical: 72 hours, High: 14 days, Medium: 30 days). For compliance, keep artifacts: SAST scan reports (timestamped), DAST reports with POC requests, WAF rule change approvals, and triage meeting notes. Automate evidence collection where possible: archive CI artifacts to a central compliance bucket, forward DAST reports to the issue tracker, and send WAF logs to your SIEM with immutable storage and access logs to prove tamper-evidence.
Risks of not implementing the mapping correctly
Failing to map controls to documented requirements increases the chance of misconfiguration, gaps in coverage, and missed vulnerabilities—leading to data breaches, service disruption, and non-compliance penalties. For a small business, a single unmitigated SQL injection or authentication flaw can expose customer PII and cause regulatory fines, contractual breach, or reputational damage. Auditors will flag undocumented controls as ineffective even if the tooling exists, so the mapping is low-cost risk reduction.
Compliance tips and best practices
For small teams: prioritize tools that integrate with existing workflows (CI, issue tracker, cloud console) and start with a minimum viable mapping for critical apps (customer-facing login, payment, user data endpoints). Use templates for mapping entries and a change-control process for rule updates. Maintain a “control cookbook” with sample configurations (Semgrep ruleset link, ZAP authentication script, WAF rule JSON) to speed audits and onboarding. Periodically validate the mapping with tabletop exercises or red-team checks and update the matrix after any architecture changes.
Summary: To comply with ECC – 2 : 2024 Control 2-15-1 under the Compliance Framework, document specific requirements for external web apps and map each requirement to the technical control(s) (SAST, DAST, WAF), tools, configurations, owners, and evidence. Use a single mapping artifact, automate evidence capture, tune tools to reduce noise, and enforce remediation SLAs—this approach makes your security controls auditable, measurable, and effective at reducing real risk.
