Appcircle Software Development Lifecycle (SDLC) Policy¶

Effective date: 2026-02-05 Last reviewed: 2026-02-05 Policy owner: Engineering Management (Security Program Owner)

Purpose¶

This policy defines Appcircle's requirements for developing software in a consistent, secure, and repeatable manner. It establishes the phases of the software development lifecycle, the security controls that apply throughout, and the standards for protecting customer data and production environments during development and testing.

This policy operates alongside the Change Management Policy, which governs the controlled promotion of changes through environments and into production.

Scope¶

This policy applies to:

All software developed, modified, or maintained by Appcircle's engineering teams.
All personnel involved in the design, development, testing, or deployment of Appcircle software.
Third-party cloud services and components incorporated into Appcircle's systems.

Development lifecycle phases¶

Appcircle's software development follows a structured set of phases:

Need identification: The business or technical need is identified and a decision is made to commit resources to address it.
Requirements definition: User requirements are decomposed into detailed functional and non-functional specifications. Security requirements and controls are identified through a security assessment at this stage.
System design: Requirements are translated into architectural and technical specifications addressing functional, security, and scalability considerations.
Build and test: Code is written, unit-tested, and integrated. Testing includes coverage of security vulnerabilities. System documentation is produced in parallel.
Evaluation: The system is evaluated to confirm it meets user and security requirements. Independent testing is performed where possible to verify quality, performance, and security.
Deployment: Changes are deployed to production after satisfying all required checks, in accordance with the Change Management Policy.

Security controls in development¶

The following security requirements apply throughout the development lifecycle:

Separation of duties: Development, testing, and production environments are logically separated. Access to production is not granted by default as a consequence of a development or testing role; it is provisioned explicitly based on documented operational need, in accordance with the System Access Control Policy.
Peer code review: All code changes are reviewed by at least one person other than the author, with reviewers expected to be knowledgeable in secure coding practices.
Secure coding standards: Developers follow secure coding standards. Annual security training is required for all personnel writing or supporting code for customer-facing or internet-exposed applications. Training must include OWASP top 10 awareness and secure development principles.
OWASP compliance: All software deployed on Appcircle's infrastructure must prevent security issues addressed by OWASP top 10 and SAN standards.
Change control for production: All changes to production environments require human approval from an authorised owner of that environment. Automated updates without such approval are not permitted.
Removal of test credentials: Custom accounts, default user IDs, and test credentials must be removed from applications before they are released to production or customers.
Secure error handling: Error messages must not expose sensitive information about system internals.

Production data protection¶

Production data must not be used in development or testing environments. This prohibition is enforced by default. Where exceptional use is unavoidable, the following controls apply:

Management approval is required before production data is used for testing.
Data must be tokenised, anonymised, or de-identified wherever possible.
Testing must use a separate copy of data; loading confidential production data to a laptop for testing is not permitted.
Data must not be extracted or handled in a manner that risks unauthorised disclosure.
Production data used in testing must be securely erased upon completion.

Data portability and API security¶

Appcircle provides APIs to customers to support programmatic access to their data and service integrations. API security considerations are addressed during development and updates:

APIs are authenticated and authorised in accordance with the System Access Control Policy.
Network protocols used for data transmission are cryptographically secure and standardised.
Security tests for interoperability and portability systems are executed and documented; results are available to customers under contractual agreements or upon request.

Customer agreements include provisions specifying access to data upon contract termination, including data format, retention period, and deletion timeline.

Roles and responsibilities¶

Engineering Management (Policy Owner): Accountable for this policy; ensures implementation, enforcement, and review; approves exceptions.
Engineering: Responsible for monitoring adherence and handling non-compliance.
Developers: Follow all SDLC requirements; complete mandatory security training; report security concerns during development to Engineering Management.
All personnel: Read, acknowledge, and adhere to this policy.

Regulatory alignment¶

This policy supports compliance with:

SOC 2 (Trust Services Criteria — Change Management, Common Criteria)
ISO/IEC 27001:2022 (A.8.25–A.8.31 Secure development lifecycle)
GDPR (Article 25 — Data protection by design and by default)
KVKK (Article 12 — Data security obligations)

Exceptions¶

Exceptions to this policy must be:

Documented with justification, scope, duration, and compensating controls.
Approved by the policy owner or an authorised delegate.
Reviewed before expiry and retired when no longer required.

Policy review and updates¶

This policy is reviewed at least annually and when significant changes occur to development practices, tooling, or regulatory requirements.

Note

This public policy describes Appcircle's SDLC requirements at a high level. Detailed internal procedures (including specific security training programmes, code review workflows, environment access configurations, and QA test standards) are maintained separately and may be shared under appropriate agreements when required.

Information Security Policy
Change Management Policy
Vulnerability Management Policy
Network Security Policy
System Access Control Policy
Logging and Monitoring Policy