Supplemental Documentation
(Annex A.14)
Public version
Effective Date: 01 July 2025
Owner: CTO
Applies To: All employees, all users of Advntg.AI
This policy supports compliance with the following standards and controls:
IISO 27001 Annex A Controls
SOC 2 Trust Services Criteria
Table of Contents
1. Purpose
2. Scope
3. Secure Development Lifecycle (SDLC)
4. Code Security Controls
5. Access and Authentication
6. Vulnerability Management
7. Third-Party Components and Dependencies
8. Secure Deployment and Change Management
9. Logging and Monitoring
10. Incident Response for Applications
11. Training and Awareness
This policy ensures that all applications developed, acquired, deployed, or maintained by the Company are secure, resilient, and compliant with regulatory and contractual obligations. Security must be integrated throughout the application lifecycle to minimize risks of unauthorized access, data breaches, or service disruptions.
This policy applies to:
3.1. Security Requirements Definition
Security requirements must be documented and integrated during both the requirements gathering and design phases of application development. These requirements must address authentication, authorization, data protection, logging, and compliance obligations.
3.2. Threat Modeling
All critical applications must undergo a formal threat modeling exercise to identify potential attack vectors, assess risks, and define mitigation strategies prior to development.
3.3. Secure Coding Practices
Development must follow secure coding standards aligned with the OWASP Top 10 and other industry-recognized guidelines. Secure coding checklists must be used to validate code before release.
4.1. Static Application Security Testing (SAST)
All application source code must undergo SAST during the development phase to identify vulnerabilities early in the lifecycle.
4.2. Dynamic Application Security Testing (DAST)
DAST must be conducted on all applications prior to production release to detect runtime vulnerabilities in the deployed environment.
4.3. Manual Security Code Reviews
Critical applications must receive a formal, peer-based security code review in addition to automated testing.
Reviews must focus on authentication logic, data validation, error handling, and other security-sensitive components.
4.4. Removal of Debugging Tools and Unused Code
All debugging tools, test scripts, and unused code must be removed from the application before deployment to reduce attack surface and prevent unauthorized access.
5.1. Role-Based Access Control (RBAC)
All applications must implement role-based access control, ensuring that users can only access features and data necessary for their job responsibilities.
5.2. Multi-Factor Authentication (MFA)
MFA is required for all administrative and privileged application accounts, using at least two authentication factors from different categories (something you know, something you have, something you are).
5.3. Secure API and Service Account Management
API keys, tokens, and service accounts must:
6.1. Regular Scanning
All applications must undergo regular vulnerability scans using Company-approved scanning tools to identify security weaknesses in code, configuration, or dependencies.
6.2. Remediation Timelines
All identified vulnerabilities must be tracked in the Company’s issue management system and remediated according to severity-based Service Level Agreements (SLAs):
6.3. Third-Party Updates & Patching
Security patches and version updates for third-party applications, libraries, and frameworks must be applied promptly based on vendor advisories and in accordance with the Company’s change management process.
7.1. Approved Libraries and Frameworks
Only Company-approved libraries, frameworks, and software components may be used in application development. Approval must be documented and granted by the application security team or designated authority.
7.2. Component Inventory
An up-to-date inventory of all third-party components, including version numbers and source repositories, must be maintained for every application. This inventory must be reviewed periodically to ensure accuracy.
7.3. Vulnerability Monitoring and Patching
All third-party components must be continuously monitored for published vulnerabilities, including but not limited to Common Vulnerabilities and Exposures (CVEs).
Identified vulnerabilities must be assessed for impact and patched in accordance with the Company’s Vulnerability Management SLAs (see Section 6.2).
8.1. Segregated Environments
All application deployments must use segregated environments for development, testing, and production to prevent unauthorized changes and reduce the risk of introducing vulnerabilities into live systems.
8.2. Security Testing and Change Approval
All changes to applications, configurations, or infrastructure must:
8.3. Automated Deployment Pipelines
Deployment pipelines must be automated to reduce human error and must produce detailed audit logs capturing:
9.1. Security Event Logging
All applications must generate logs for security-relevant events, including but not limited to:
9.2. Log Retention
Application logs must be retained in accordance with the Company’s Log Retention Policy and stored in a secure, tamper-resistant format to ensure integrity and availability for audits or investigations.
9.3. SIEM Integration
All application logs must be integrated with the Company’s Security Information and Event Management (SIEM) system to enable centralized monitoring, correlation of events, and automated alerting on suspicious activity.
10.1. Alignment with Corporate Incident Response Plan
All application-related security incidents must be handled in accordance with the Company’s Incident Response Plan (Annex A.16), including detection, containment, eradication, recovery, and lessons learned.
10.2. Application-Specific Playbooks
Development teams must maintain application-specific incident response playbooks to address common security threats such as:
Playbooks must include detection methods, containment steps, and remediation actions, and should be reviewed and updated at least annually.
11.1. Secure Coding Training
All developers, architects, and QA engineers involved in application design or development must complete secure coding training at least annually.
Training must cover:
11.2. Security Champions Program
Each development team must designate a Security Champion responsible for promoting security best practices, facilitating peer reviews, and serving as the liaison with the Information Security Team.
11.3. Awareness Reinforcement
Application security awareness must be reinforced through periodic updates, bulletins, and targeted refresher sessions, especially in response to newly discovered threats or incidents.
This Policy shall be reviewed and edited from time to time, subject to the CTO’s approval.
For questions or reports regarding this Policy, contact:
* * *