Security

This working statement describes general security practices that [LEGAL ENTITY NAME], of [REGISTERED ADDRESS], expects to apply when delivering software engineering engagements. It is intended to take effect on [EFFECTIVE DATE], subject to legal and operational review. Specific controls depend on the client system, agreed scope, hosting model and allocation of responsibilities.

This statement does not claim a certification, independent audit or formal attestation. Any formal control framework, assurance report or contractual security schedule remains pending confirmation and must be agreed separately.

Engagement code should be held in access-controlled repositories approved for the work. Access should be limited to assigned personnel, reviewed when roles change and removed when no longer needed. Changes should follow the review and delivery process agreed with the client, with dependencies and security-sensitive behaviour considered as part of engineering work.

Credentials and other secrets should not be committed to source code or placed in public documentation. They should be provided through an agreed restricted channel, used only for their intended environment and replaced or withdrawn when exposure is suspected or access is no longer required. Client-specific handling requirements take priority where agreed.

A person who believes they have found a vulnerability affecting a Genisys-operated site or product should report it privately to [SECURITY CONTACT]. The report should identify the affected location, explain the observed behaviour and provide enough reproducible detail to support investigation without including unnecessary personal or client data.

Reporters should avoid disrupting systems, accessing data beyond what is necessary to describe the issue, or publishing details before a safe disclosure approach has been agreed. A formal disclosure policy, acknowledgement process and response times are pending confirmation; this draft makes no commitment about those matters.

This statement does not cover systems operated solely by a client or third party, guarantee that software is free from vulnerabilities, or replace a contract-specific threat assessment and security plan. It does not establish uptime, recovery, testing cadence, encryption specification or regulatory compliance for any engagement or product.

Clients remain responsible for decisions and controls assigned to them, including authorised users, business procedures and infrastructure they operate. Security requirements, incident responsibilities, data handling, support boundaries and any obligations under [GOVERNING JURISDICTION] should be recorded in the applicable agreement. General questions may be sent to [SUPPORT CONTACT].