Design Development Records
| Field | Value |
|---|---|
| Version | 1.0 |
| Effective Date | April 2026 |
| Review Cycle | Annual |
| Document Owner | Chief Information Security Officer (CISO) |
| Classification | CONFIDENTIAL — Internal Use Only |
| Applicable Standard | SOC 2 Type II — Security, Availability, Confidentiality |
1. Purpose and Scope
This document records the design and development processes, methodologies, and governance controls applied during the creation and ongoing enhancement of QA Touch features. It demonstrates to SOC 2 Type II auditors that the entity maintains systematic controls over the software development lifecycle (SDLC) to protect the integrity of the product and customer data, satisfying Trust Service Criterion CC8.1 (Changes to Infrastructure, Data, Software, and Procedures).
2. Software Development Lifecycle (SDLC) Overview
QA Touch follows an Agile SDLC with defined quality and security gates enforced at every stage. No code is deployed to production without passing all mandatory gates.
| SDLC Phase | Key Activities | Artefacts Produced |
|---|---|---|
| Requirements | Product Manager defines user stories and acceptance criteria. Security requirements identified. Privacy impact assessed. Stakeholder sign-off obtained. | User stories, acceptance criteria, DPIA (where required) |
| Design | Architecture review for significant features. Threat modelling (STRIDE). Data flow diagrams updated. UI/UX prototypes reviewed by Product Lead. | Architecture diagrams, threat model, data flow diagrams, API contracts |
| Development | Feature branches in version control. OWASP Top 10 secure coding enforced. Code review mandatory (minimum one senior peer reviewer). No hardcoded secrets. | Feature branch, pull request, code review record, commit history |
| Testing | QA team executes functional, regression, and integration tests using QA Touch itself (dogfooding). Security/SAST scans run on every PR. | Test plan, test run results in QA Touch, defect log, SAST report |
| Staging Validation | Full regression suite executed in staging. Performance benchmarks validated. Penetration test findings reviewed. | Staging test run report, performance test results, security checklist |
| Release / Deployment | Deployment via CI/CD pipeline with automated smoke tests. Rollback plan documented and reviewed. Change advisory record created. | Deployment record, rollback plan, release notes, change advisory record |
| Post-Release Monitoring | Error rates, performance metrics, and security alerts monitored for 24 hours post-deployment. On-call engineer assigned. | Monitoring dashboard, incident log (if any), post-deploy checklist |
3. Design Controls
3.1 Requirements Traceability
- All development tasks trace to a documented user story or business requirement with a unique ID.
- QA Touch’s own RTM (Requirements Traceability Matrix) feature is used to link requirements to test cases, ensuring every requirement is covered by at least one test case before release.
- Changes to requirements after sprint commitment require a formal change request, impact assessment, and Product Manager re-approval.
3.2 Architecture and Threat Modelling
- Significant new features or architectural changes require a Design Review meeting with the Engineering Lead and Security Engineer.
- Threat modelling is performed using the STRIDE methodology for features that: handle new data types, introduce new third-party integrations, or modify authentication/authorisation flows.
- Data flow diagrams are updated whenever the collection, storage, processing, or sharing of customer data changes.
ASSUMPTION: Threat modelling tool (e.g., OWASP Threat Dragon) and cadence of design reviews must be confirmed with the engineering team.
3.3 Secure Coding Standards
- OWASP Top 10 secure coding guidelines are mandatory for all engineers.
- Input validation and output encoding enforced at API and application layers; parameterised queries used for all database operations.
- No hardcoded credentials, API keys, or secrets in source code — enforced by pre-commit hooks and SAST scanning.
- All third-party dependency versions pinned; automated CVE alerts (Dependabot / Snyk [VERIFY]) reviewed weekly.
4. Testing and Validation Records
| Test Type | Description | Tooling / Owner / Frequency |
|---|---|---|
| Unit Testing | Validates individual functions and modules in isolation. | Developer-owned; per commit; [VERIFY: Jest / pytest] |
| Integration Testing | Tests interactions between application components and external services. | QA team; per release sprint |
| Functional / Acceptance Testing | End-to-end validation against user story acceptance criteria using QA Touch test runs. | QA team (dogfooding QA Touch); per feature release |
| Regression Testing | Full test suite to confirm no existing functionality is broken by new changes. | QA team; every release candidate |
| Security / SAST | Static analysis of source code for vulnerabilities and insecure patterns. | Security team; [VERIFY: SonarQube / Semgrep]; per PR + weekly |
| Dependency Scanning | Checks all third-party libraries against known CVE databases. | Engineering; [VERIFY: Dependabot / Snyk]; weekly |
| Performance / Load Testing | Validates system behaviour under normal and peak load conditions. | Engineering / DevOps; [VERIFY: k6 / JMeter]; quarterly + major releases |
| Penetration Testing | Independent external security assessment of the production environment. | Third-party security vendor; annually |
| User Acceptance Testing (UAT) | Beta testing with selected customers or internal stakeholders for major releases. | Product team; on major feature milestones |
5. Change Management Controls
- All code changes must be submitted as pull requests (PRs) and pass all automated CI checks before merge is permitted.
- Peer code review is mandatory; approval from at least one senior engineer is required for changes touching production-critical paths (authentication, billing, data access layer).
- Emergency hotfix changes follow an expedited review process but must receive post-facto peer review and documentation within 24 hours of deployment.
- Database schema changes require a tested, reversible migration script reviewed by the DBA before staging deployment.
- All production deployments are logged with timestamp, deployer identity, version deployed, and associated change record.
- Deployment frequency, lead time, change failure rate, and MTTR are tracked as DORA metrics and reported monthly to Engineering leadership.
6. Record Retention
- Test run results in QA Touch: retained for project duration plus 12 months.
- Security scan (SAST) reports: retained for 24 months.
- Penetration test reports: retained for 36 months; shared with auditors under NDA.
- Pull request and code review records: retained in version control system indefinitely.
- Deployment records: retained for 36 months in CI/CD and change management systems.