ABCDELMOPQRSTUVWXYZ
1
To include the final SbD Compliance Responses from the Awarded Contractor's RFP/RFQ submission
Do not include/share this spreadsheet in the RFP/RFQ documents.		(For Reference) Guidance for Evidence Collection
Do not include in the RF(X) documents
2
 Updated by:
System Owner/Vendor		Updated by:
System Owner/Vendor
3
SNCategory
(Type of Security Requirement)		Security Requirement Details
(List of security requirements to be fulfilled as part of the Secure-by-Design Governance Framework)		Compliance
(Yes/No/Partial/N.A.)		Comments
(To include comments where there is non-compliance, or other notable points)		SbD Design Document
Details to Include		SbD Documentation
Evidence Requirements
4
1GeneralThe Contractor shall fulfil all Secure-by-Design (SbD) requirements listed in this document/checklist.

In the event of non-compliance to any SbD security requirements, a risk assessment shall be conducted, along with the implementation of approved / agreed-upon mitigating controls.		N.A.Completed risk assessment documents and evidence that mitigating controls are implemented (only if applicable, where there is non-compliance to the rest of the SbD requirements in this checklist)
5
2GeneralFor Secure-by-Design requirements that are part of the security requirements in Keppel's Technology Policies or Keppel's Cyber Security Standards, a non-compliance of any of such requirements shall follow Keppel's policy or standards deviation and approval process.

Note: Mapping of the SbD requirements to relevant Keppel's policies and standards will be shared during System implementation.		N.A.Approved policy/standards deviation documents (only if applicable, where there is non-compliance to the rest of the SbD requirements that contain a Keppel policy/standards reference)
6
3Third Party AccessKeppel shall approve all Contractor personnel access to the System, and access granted shall be based on implementation and/or operational requirements.

Note: Access to Keppel's network, where required, should be limited to the networks and systems that the contractor is implementing or maintaining.		N.A.Keppel approvals for Contractor access (3 samples)
7
4Third Party AccessAll Contractor personnel requiring access to Keppel's network shall be briefed on Keppel’s “End User Computing Policy” and applicable IT security policies and sign an undertaking form to comply with the policy.N.A.Signed undertaking forms from Contractor personnel (3 samples)
8
5Third Party AccessComputing equipment from the Contractor's personnel that require remote access to Keppel's network shall be installed with Keppel's virtual private network (VPN) solution.N.A.Screenshots of Pulse Secure VPN installed on Contractor devices (3 samples)
9
6Third Party AccessComputing equipment from the Contractor's personnel that require access to Keppel's network shall include the following security protection, and subject to Keppel's inspection before being allowed into Keppel's network:

• Anti-malware protection with up-to-date malware definitions
• Endpoint detection and response (EDR) protection		N.A.1. Screenshots of anti-malware (with up-to-date definitions. To show that definitions are up-to-date, please capture system date/time in screenshot) (3 samples)
2. Screenshots of EDR on Contractor devices (3 samples)
10
7Threat and Risk AssessmentThe Contractor shall conduct a Threat and Risk Assessment (TRA) on the System and implement applicable recommendations from the assessment.

The TRA is to be performed to systematically identify threats and vulnerabilities to the System, determine the level of risks the System is exposed to, and to recommend the appropriate levels of protection. A typical TRA includes:
• Review based on functional & design specifications
• Identification of threats and vulnerabilities
• Identification, analysis and evaluation of risks
• Recommending appropriate security controls

Note: TRAs are only applicable for Keppel systems classified as critical (and excludes SaaS-based systems that are ISO27001 and/or SOC 2 Type 2 certified)		N.A.Final TRA report of the System and evidence that approved / agreed-upon mitigating controls are implemented.
11
8Threat and Risk AssessmentThe Contractor shall conduct regular Threat and Risk Assessments (TRA) (every 3 years) upon System go-live, where a yearly self-assessment checklist shall be used during the years that the regular TRA is not conducted.

Note: TRAs are only applicable for Keppel systems classified as critical (and excludes SaaS-based systems that are ISO27001 and/or SOC 2 Type 2 certified)		N.A.Procedures in the System operations runbook (or equivalent documentation) stating that a Keppel self-assessment TRA checklist will be used in the first 2 years of System operations, and a full TRA will be conducted year 3, and for the cycle to repeat every 3 years.
12
9Security Architecture
& Design		The Contractor shall develop and maintain a security design document. This document shall include security design details for all relevant security clauses within this Secure-by-Design checklist.

Note: For SaaS-based solutions, only application-layer security requirements listed in this Secure-by-Design document/checklist are applicable and to be included in the security design document.		N.A.Keppel-approved security design document (or equivalent detailed design document containing security details)
13
10Security Architecture
& Design		Production environments (e.g. production or DR sites) should be separate from the non-production environments (e.g. UAT or development environments) and no production data should be used in the non-production environments.

Note: In the event production data is used in a UAT environment (subject to required approvals), the UAT environment shall employ the same level of security as the production environment.		- Overall system architecture diagram (and its components) and detailed design descriptions (e.g. interactions between components and purpose of the interactions)1. Screenshots of AWS VPC or Azure VNet allocations for production, UAT and dev environments (both production and DR sites where applicable)

2.1 Screenshots of UAT database data query (3 samples and including hostname of UAT database server) showing no production data
2.2 If approval given to use production data in UAT, provide a PDF copy of the approval.
14
11Security Architecture
& Design		A multi-tier architecture shall be used for the implementation of the System. An example of a multi-tier architecture is as below:
• Presentation tier (web server serving user interface elements)
• Application tier (where application logic / computing resides)
• Data tier (holds and manages System data)

Where required, the presentation tier can be internet-facing, while the other tiers should be hosted in secure private networks / zones.		- Listing (and details of) all VPN/VNet allocations for the different tiers in the System
- Details that VPN/VNet are protected by virtual firewalls		1. Screenshots of AWS VPC or Azure VNet allocation for production environment, showing a multi-tier architecture.
2. Screenshots that each VPN/VNet is protected by virtual firewalls (e.g. AWS Security Groups, Azure Network Security Groups)

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
15
12Infrastructure SecurityOpening of firewall ports in applicable Keppel firewalls for System use shall be reviewed and approved by Keppel IT COE's Change Approval Board before implementation.N.A.IT COE Change Approval Board approval (3 samples)
16
13Cloud SecurityTo demonstrate that security best practices are followed, please provide the following:
1. System and Organisation Control (SOC) 2 Type 2 requirements
2. ISO/IEC 27001 certification

Applicability of certifications is based on the following scenarios:
1. SaaS-based solution: Certifications of the SaaS solution
2. Applications hosted on non-standard / custom-built environments (e.g. ESXi hosts located in a data centre): Certifications of the underlying infrastructure

Note: If the application is hosted on AWS or Azure, evidence of certifications is not required.		N.A.PDF copies of the SOC 2 Type 2 and/or ISO 27001 certifications
17
14Cryptography & Key ManagementThe System shall minimally support the following cryptographic standards:
• Symmetric Encryption - AES 256 or better
• Asymmetric Encryption - RSA 2048 / ECC 256 or better
• Digital Signature - DSA 2048 / RSA 2048 / ECDSA 256 or better
• Hashing Algorithm - SHA 256 or better
• Key Exchange - ECDH 256 / FFDH 2048 (p) 224 (q) / RSA 2048		Note: Design details for encryption will be provided in subsequent SbD cryptography-related clauses.Encryption details included in the security design document (or equivalent documentation)
18
15Cryptography & Key ManagementAccess to the cryptographic key store (e.g. AWS KMS, Azure Key Vault) used by the System shall be limited to authorised personnel only (e.g. system/security administrators).- Details of cryptographic key store used
- Listing (and details of) all data-at-rest and data-in-motion System component encryption with keys from the key store		Screenshot(s) of list of users with access to the key store and their access privileges in the production environment.

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
19
16Cryptography & Key ManagementCryptographic keys used by the System for data encryption (e.g. SQL databases, AWS S3 buckets, Azure Block Storage etc.) shall minimally be rotated on a yearly basis.N.A.For AWS or Azure: Screenshots of key rotation setting configured for yearly rotation in the production environment.
For manual key rotation: Procedures in the System operations runbook (or equivalent documentation) describing the rotation of data encryption keys.

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
20
17System & Application SecurityThe Contractor shall ensure that all relevant System components (e.g. operating systems hosting the installed applications, Kubernetes etc.) are hardened based on Keppel-approved standards (e.g. CIS benchmarks)- Listing (and details of) all System components and their corresponding hardening (e.g. CIS benchmark)
- How hardening is enforced. e.g. Windows GPO		For Windows server joined to Keppel's domain, to share the gpresult text file export (e.g. gpresult /r >c:\results_<hostname>.txt) and GPOs applied on the server.

For Linux servers, to share hardening scan reports showing that the hardening settings are configured.
21
18System & Application SecurityThe Contractor shall ensure that all proposed components of the System are not End-Of-Life (EOL) or End-Of-Support (EOS) within the contract period for both mandatory and optional purchases.

If any of the proposed components reach EOS or EOL within the contract period, the Contractor shall upgrade the components to software versions that are not EOS or EOL.		N.A.1. Screenshots of the awarded contract period
2. Official production documentation stating the EOL and EOS of the installed applications in the System.
3. Where EOS or EOL falls within the contract period, to provide an official confirmation (email or otherwise) that the components will be upgraded as required.
22
19System & Application SecurityAccess to the System's user interfaces (e.g. web UI, database UI login) and communication with other systems (e.g. system-to-system connectors, API calls) shall minimally include the following:
1. Enable transport layer security (TLS) 1.2 or above (use of Web Services (WS) Security on top of TLS is encouraged for highly sensitive API communication)
2. Use of only strong cipher suites

As there are weak cipher suites in TLS 1.2, only the following cipher suites should be enabled (the rest of the TLS 1.2 cipher suites should be disabled)
1. TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
2. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
3. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Note: Weak cipher suites can be disabled on Windows servers using Group Policy Objects (GPOs).		- Listing (and details of) all data-in-motion (e.g. TLS cipher suites) encryption used for System to user and System to system communication
- How is hardening enforced. e.g. Windows GPO for disabling of weak TLS cipher suites

Note: to include crypto algorithm and key strength		Screenshots of TLS encryption configuration (i.e. weak cipher suites shown as disabled). For Windows servers, IIS Crypto can be used to show disabled cipher suites.

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
23
20System & Application SecurityFor web-based applications, the Contractor shall implement the following web application security controls:

1. Enable HTTP Strict Transport Security (HSTS) to enforce HTTPS communication between the user and application
2. Implement Content Security Policy (CSP) to mitigate risks such as cross-site scripting (XSS) attacks
3. Validate and sanitize user input to prevent exploits such as SQL injection and cross-site scripting (XSS).		N.A.1. Final VA reports (with all findings remediated) of VMs in the System running the web servers. (Production environment preferred)
2. Final PT reports (with all findings remediated) of all applicable web application installed on the System.
24
21System & Application SecurityFor web-based applications, the Contractor shall implement the following session management controls:

Stateful applications
1. Enable HttpOnly for session cookies, to prevent client-side scripts access to cookie information, to mitigate risks such as cross-site scripting (XSS) attacks

Stateless applications
1. Enable HttpOnly for session cookies, to prevent client-side scripts access to cookie information, to mitigate risks such as cross-site scripting (XSS) attacks
2. Implement secure handling of tokens such as using JSON Web Tokens (JWT)		N.A.1. Final VA reports (with all findings remediated) of VMs in the System running the web servers and application servers. (Production environment preferred)
2. Final PT reports (with all findings remediated) of all applicable web application installed on the System.
25
22System & Application SecurityThe System shall be configured with user session expiration timeouts or lockouts (e.g. defined within configuration files in Tomcat, WebLogic, Microsoft IIS etc.)

Note: For SaaS-based applications, the Contractor shall ensure that session timeouts are configured by the SaaS-based solution provider.		- Listing (and details of) all application components used for user interfacing and session timeout values.For SaaS applications: Documentation from SaaS application vendor that session timeout is enabled

For non-SaaS applications: Screenshots of configured user session expiration timeout

Note: If production data in used in UAT, provide a separate set of evidence/reports for the UAT environment.
26
23System & Application SecurityDigital Certificates shall be used as follows:
• System's internet-facing interface: Certificates from public recognised certificate authorities (CA). e.g. Global Sign / DigiCert
• System's non-internet facing interface: Certificates from Keppel's internal CA (maximum validity of 3 years)

Notes:
• Requirements apply to all production and non-production systems
• Wildcard certificates from public CAs are only allowed for non-production systems that do not contain sensitive Keppel data (e.g. DEV environments)
• Self-signed certificates are not allowed on any production and non-production systems		- Listing (and details of) all certs used for internet-facing communication (either to users or to other systems/components)
- Listing (and details of) all certs used for System's internal communication		Screenshots of certs used (ensure browser URL is captured in screenshot) for all public CA and Keppel internal CA certificates. This includes:

• All Internet-facing interfaces (production, UAT and dev web servers)
• All internal comms within application (i.e. between application components) for production, UAT and dev. Applicable only if separate certificates are required for internal component to component communication.
27
24System & Application SecurityDigital certificates used shall fulfil the following requirements:
• Comply with X.509 v3 standards
• Use of strong encryption (refer to clause 19 of this SbD checklist)		N.A.Export public CA and Keppel internal CA certificates used with ".crt" extension. This includes:

• All Internet-facing interfaces (production, UAT and dev web servers)
• All internal comms within application (i.e. between application components) for production, UAT and dev. Applicable only if separate certificates are required for internal component to component communication.
28
25System & Application SecurityFor any system-to-system communication, service accounts shall be used (e.g. integration/communication with other systems, such as API calls, or within the components of the same system, such as application servers to databases). These service accounts shall only be used for system-to-system and not by users logging into and using the System.- Listing (and details of) all system-to-system communication that uses service accountsScreenshots of service account configuration for all systems-to-system communication in the production environment.

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
29
26System & Application SecurityService accounts used by the System shall have interactive login disabled (e.g. for Windows, to enforce "Deny log on locally" and "Deny log on through Remote Desktop Services" in the Group Policy Object)

Note: For service account creation requests with Keppel's IT Shared Services, please indicate that interactive login for the service account should be disabled.		N.A.Screenshots of Keppel service account SR approval, with SR details on list of account IDs created, and that interactive login for the service account shall be disabled.
30
27System & Application SecurityApplications (i.e. software that provide the key functionality of the System) installed in the System shall be free of malware (i.e. scanned by anti-malware software before uploading to the System).N.A.Screenshots of malware scan results (e.g. in laptop where software is transferred to a VM) of all application software used.
31
28System & Application SecurityAll servers and VMs that are part of the System shall be installed with the following endpoint protection software:

• Anti-malware protection with up-to-date malware definitions
• Endpoint detection and response (EDR) protection		N.A.Screenshots of server/VM OS (including hostname in the same screenshot) with anti-malware installed (with up-to-date definitions), and EDR installed in the production environment. (3 samples)

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
32
29System & Application SecurityThe System development team shall not have rights to deploy code to the UAT and Production environments. Code deployment shall be handled by a separate team to ensure segregation of duties.

Note: This applies as well to deploying container images from DEV to UAT and Production environments.		N.A.1. Configuration screenshots in code repository on access granted (to developers) to upload (and/or download) code
2. Configuration screenshots in code repository on access granted (non-developers) to download code (for code uploading purposes)
3. Configuration screenshots of access granted (non-developers) to UAT and Production servers where the code is uploaded to.
33
30System & Application SecurityThere shall be clear accountability (i.e. approvals for code deployment and appropriate user roles/rights allocated for code deployment) and traceability (audit logs for code deployment performed) for all software code that are deployed to UAT and Production environments.

Note: This applies to deploying container images from DEV to UAT and Production environments as well.		N.A.1. Code deployment workflow details as part of the System operations runbook (or equivalent documentation)
2. Screenshots of approvals for uploading code to UAT (3 samples)
3. Screenshots of approvals for uploading code to Prod (3 samples)
34
31API SecurityThe following API authentication methods shall be used for API access:
• API keys used with single token strings
• Authentication with user ID and password
• OpenID Connect on top of the OAuth framework		- Listing (and details of) all APIs used (both incoming and outgoing) and the authentication method used. Configuration screenshots of all APIs used in the production environment.

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
35
32API SecurityAll API calls received by the System (from other systems) shall have input validation (e.g. data types, data formats and content length checks) to prevent attacks like injection attacks (e.g XSS).

Note: This requirement is fulfilled if relevant Penetration Tests (that include testing of the application software's APIs) are performed by the product vendor prior to the installation of the software in Keppel's environment.		N.A.1. Screenshots of the version of application software installed in both the production and UAT environments.
2. PenTest reports (with all findings remediated and on the version of the software used) from the product vendor, showing API testing as part of the PT scope.
36
33Data & Information SecurityAll Highly Confidential Keppel data, Confidential Keppel data, and Personal Identifiable Information (PII) shall be encrypted while stored on fixed media (e.g. file repositories, databases, data lakes, backup etc.).- Listing (and details of) all data-at-rest (e.g. S3/blob storage/backup) encryption used and the type of data encrypted

Note: to include crypto algorithm and key strength		All screenshots of encryption being enabled on disk/database/S3 buckets/Azure Blob storage/backup media etc., in the production environment.

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
37
34Access Control and ManagementFrom a system design perspective, the Contractor shall design System access rights based on the principle of least privilege and need to know (i.e. defining role-based access for users with different system privileges for the relevant installed applications, operating systems or container resources).

Note: The design document shall include details of the user roles configured for System day 2 operations/use.		- Listing (and details of) all roles being defined in the System (including installed applications, OS, container (if any) resources etc.)User role-based access design and details (e.g. list of roles and their assigned privileges in system) in the security design document.
38
35Access Control and ManagementApplication(s) in the System shall have the technical capability/functionality to configure Role-Based Access Control (RBAC) and role-based access shall be configured for user access to the System.N.A.1. Official product documentation that role-based access is technically supported.
2. Screenshots of users in the system and their assigned roles in the production environment.

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
39
36Access Control and ManagementApplication(s) in the System shall have the technical capability/functionality to create, update, deactivate and remove user accounts and profiles.N.A.Official product documentation from product vendor (e.g. user guide on how to manage user accounts)
40
37Access Control and ManagementApplication(s) in the System shall have the technical capability/functionality to list and/or export user access privileges (i.e. the application can show/export users with their assigned privileges/roles)

Note: This system (and components) functionality is used to support User Access Review requirements listed in clause 45.		N.A.Official product documentation from product vendor (e.g. user guide on how to export a list of users and their assigned privileges)
41
38Access Control and ManagementApplication user logins shall only show generic login errors (e.g. Incorrect username or password).

Note: Systems that fully integrate with Keppel's Azure AD / Entra ID (i.e. no user accounts, such as an application super user account, that still use local application logins) will have fulfilled this requirement.		N.A.1. Screenshot of the SAML configuration in AAD/Entra ID for SSO in the production environment (to request screenshot from Keppel ITSS)
2. If accounts using native/local application logins are still allowed, screenshots of user login error message from the application's native login.

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
42
39Access Control and ManagementUnique user identities shall be used to ensure users are held accountable for the activities / actions performed. Generic user identities are not allowed.

Note:
• This requirement is not applicable to service accounts
• Systems that fully integrate with Keppel's Azure AD / Entra ID will have fulfilled this requirement.		N.A.1. Screenshot of the SAML configuration in AAD/Entra ID for SSO in the production environment (to request screenshot from Keppel ITSS)
2. Screenshot that all native/local application user IDs are removed/disabled in the production environment

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
43
40Access Control and ManagementPrivileged user access to systems classified as critical systems shall be via a privilege access management (PAM) solution where access to the System is controlled and monitored.

Note: This is not applicable for SaaS-based solutions, where privileged user access is controlled by conditional access and MFA.		- Listing (and details of) all System components accessed via PAMScreenshots of PAM access to all applicable System components in the production environment.

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
44
41Access Control and ManagementThe System shall support Single Sign-On (SSO) integration via the SAML 2.0 or OAuth protocols and integrate with Keppel's Azure Active Directory (Microsoft Entra ID).- Listing (and details of) SSO integration of all System componentsScreenshot of the SAML configuration in AAD/Entra ID for SSO in the production environment (to request screenshot from Keppel ITSS)

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
45
42Access Control and ManagementMulti-factor authentication (MFA) via Keppel's Azure Active Directory shall be used for all user access and as follows:
• Non-privileged users are required to perform MFA every 30 days
• Privileged users are required to perform MFA upon every login

Notes:
• Privileged user accounts IDs shall use the following naming convention: admin_<username>@xxx
• In the case of "MFA upon every login" for privileged users, the Contractor shall raise a Service Request with Keppel's IT Shared Services to enforce this setting with Keppel's Azure AD (Entra ID) Conditional Access Policy		N.A.1. For non-privileged users, screenshots of MFA prompt during login

2. For privileged users, screenshots of MFA with admin_<username>@xxx naming convention, and screenshot of completed/closed Service Request indicating MFA performed on every login in AAD Conditional Access Policy.

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
46
43Access Control and ManagementAccess rights of users, including temporary staff, who have resigned or are no longer part of the System implementation or maintenance team shall be removed as follows:
• Regular user access: No later than 3 days
• Privileged user access: Within 1 day

Note: Systems that fully integrate with Keppel's Azure AD / Entra ID (i.e. no user accounts, such as an application super user account, that still use native application logins) will have fulfilled this requirement.		N.A.1. Screenshot of the SAML configuration in AAD/Entra ID for SSO in the production environment (to request screenshot from Keppel ITSS)
2. Screenshots that all native/local application user IDs are removed/disabled in the production environment

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
47
44Access Control and ManagementUser access rights shall be reviewed periodically and accounts that are no longer required shall be disabled, where the review frequency is as follows:
• Regular user access rights: Critical Systems - twice a year
• Regular user access rights: Non-critical systems - yearly
• Privileged user access rights (critical and non-critical systems): twice a year		N.A.UAR operational process flow chart and descriptions as part of the System operations runbook (or equivalent documentation)

Note: If production data in used in UAT, provide details that UAR will be performed in the UAT environment, following the same UAR operational process flow.
48
45Password Management(Interactive) User accounts (e.g. web applications IDs, database IDs such as "sa" or operating system IDs in Windows or Linux) accessing the System shall comply to Keppel's password policy as follows:
• Minimum Password Length: Minimum of 8 characters
• Password Complexity: At least a combination of symbols, upper-case and lower-case characters
• Maximum Password Age: 90 days
• Password History: At least 8 previously used passwords
• Account Lockout Duration: Minimum of 30 minutes
• Account Lockout Threshold: Maximum of 6 invalid login attempts
• Account Lockout Action: Account disabled

Note: Systems that fully integrate with Keppel's Azure AD / Entra ID (i.e. no user accounts, such as an application super user account, that still use local application logins) will have fulfilled this requirement.		- Listing (and details of) all native application logins and their corresponding password complexity used

Note: Applicable only if native application logs are enabled		1. Screenshot of the SAML configuration in AAD/Entra ID for SSO in the production environment (to request screenshot from Keppel ITSS)
2. Screenshots that all native/local application user IDs are removed/disabled in the production environment

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
49
46Password ManagementPasswords of applications installed on the System shall not be stored in clear text (e.g. stored as password hashes within the application's database).

Note: This SbD check is not required for passwords on standard operating systems (e.g. Windows / Linux etc.) used by the System, where these passwords are recognised/known to be stored in hashes.		N.A.Screenshots of hashed application passwords (e.g. from SQL database if application password hash is stored in the database).
50
47System Patch ManagementThe Contractor shall develop and implement a patch management process for all relevant System components (e.g. installed applications, operating systems (OS), containers orchestrators and runtimes etc.)N.A.Application and/or OS patch management process and details as part of the System operations runbook (or equivalent documentation)

Note: If production data in used in UAT, provide details that the same patch management process will be followed in the UAT environment.
51
48System Audit LoggingAll audit logs (records of events, actions / changes within a system / application) shall be stored within the System as follows. The logs can be retained online or on backup media.

Critical Systems: At least 12 months
Non-Critical Systems: At least 3 months

Notes:
 • Audit logs of privileged user activities shall be retained and available (either stored in the System or on a separate secure audit logs store) after the deletion of the privileged user IDs in the System
• These audit logs shall be stored separately (either in the System or on a separate secure audit logs store) from Keppel's security monitoring solution
• Relevant regulatory requirements for additional log retention will supersede these requirements.		- Listing (and details of) all audit logs, logs storage location, and retention periodScreenshots of application / OS / DB etc. configuration showing that audit logs are retained for 3 months / 1 year in the production environment.

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
52
49System Audit LoggingAccess to audit logs should be restricted via strong access controls and restricted to authorised personnel only (e.g. system administrators, Keppel security team).

Note: Strong authentication controls are covered under clause 42 in SbD (under MFA for privileged user access)		N.A.For applications: Configuration screenshots of roles assigned to admin/security team (show listing of user IDs) for log access

For OS/AWS/Azure: Screenshots that access to logs folder/S3 bucket/blob is only for admin/security team (show listing of user IDs)

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
53
50Security Monitoring and Incident ManagementFor Systems classified as Critical, all system-level security-related audit logs (e.g. Windows Security Event logs, Linux /var/log/syslog or /var/log/messages via Syslog) shall be forwarded to Keppel's security monitoring solution.

For Systems classified as Non-Critical, all events of interest, including security events and privileged activities, shall be reviewed every six (6) months.		Critical Systems only
- Listing (and details of) all security-related audit logs forwarded to Keppel SOC		Critical Systems: Screenshots that security-related audit logs are observed on Keppel's Microsoft Sentinel security monitoring solution. Note: Reach out to Keppel's Cyber Security Centre (KCSC) for the onboarding and obtaining of screenshots.

Non-Critical Systems: Audit logs review process flow and details, as part of the System operations runbook (or equivalent document)

Note: If production data in used in UAT, provide a separate set of evidence/screenshots for the UAT environment.
54
51Security Monitoring and Incident ManagementFor cyber incident response matters, the following shall be established:

SaaS-based Solutions
1. Vendor alerting on incidents relevant to Keppel: Vendor SLAs for alerting Keppel (Keppel to provide contact information to receive the alerts)
2. Keppel's cyber team response on vendor alerts: Vendor contact information and response SLA

Non SaaS-based Solutions
1. Keppel's cyber team alerting to Keppel's application team: Keppel's application owner and technical in-charge (and where applicable, outsourced service provider) contact information (contactable after office hours), and solution vendor's expected response time.		N.A.SaaS-based
1. Official vendor documentation on SLAs to alert Keppel on relevant cyber incidents.
2. Screenshot of the vendor contact information and response SLA is shared with Keppel's cyber team

Non SaaS-based
1. Screenshot of the Keppel application owner and technical in-charge contact information, and vendor expected response time is shared with Keppel's cyber team
55
52Security TestingVulnerability assessments (VA) shall be conducted regularly, in accordance with the System criticality. Minimally VAs shall be conducted as follows:

Critical Systems
• Before System go-live
• Twice yearly after System go-live
• Upon major change after System go-live

Non-Critical Systems
• Before System go-live
• Annually after System go-live

Note: Ensure that the VA report lists down all system utilities/testing software installed on the VMs, such as 7-zip, Wireshark, Putty, WinSCP, Chrome, Selenium.		N.A.1. Final reports of VA scans on all applicable System components, indicating that all VA findings have been remediated. (Scanning of the production environment preferred)
56
53Security TestingThe Contractor shall engage an independent third-party to regularly conduct System penetration tests (PT), in accordance with the System criticality. Minimally PTs shall be conducted as follows:

Critical Systems
• Before System go-live
• Annually after System go-live
• Upon major change after System go-live

Non-Critical Systems
• Before System go-live		N.A.1. Final reports of PT scans on all applicable System components, indicating that all PT findings have been remediated for the UAT environment.
57
54System Go-LiveDefault System accounts shall be disabled or removed before System go-live (e.g. super user IDs from web applications, "sa" from databases, or the Windows server local administrator account. For Linux server root accounts, please disable root login over SSH).

Where System accounts are required for break-glass / emergency use, corresponding account check-out and use procedures shall be followed.		N.A.Screenshots of list of user accounts showing disabled/removed default System accounts for all relevant System components, such as web application software, SQL database (e.g. "sa" accounts), VM server etc.

If the System accounts are required, provide the operational process flow for account check-out and use, as part of the System operations runbook (or equivalent document)

Note: If production data is used in UAT, please include screenshots for both production and UAT environments.
58
55System Go-LiveFor Systems where Keppel manages the operations of the System, the Contractor shall handover all access of the System to Keppel before System go-live.N.A.Screenshots of final user list for all applicable System components, such as application software, VM server, (with no Contractor user IDs in System) in the production environment

Note: If production data is used in UAT, please include screenshots for both production and UAT environments.
59
56System Go-LiveAll system utility/testing software (e.g. 7-zip, Wireshark, Putty, WinSCP, Chrome, Selenium etc.) used during System implementation shall be removed before System go-live. Where such utilities/software are required for System operations/maintenance, they shall be regularly patched.N.A.Final reports of VA scans on all relevant System components, indicating that all VA findings have been remediated. (Production environment preferred)

Note: Ensure that the VA report shows a list of all system utility/testing software installed.
60
57System Go-LiveThe Contractor shall ensure completion of the Secure-by-Design assessment before System go-live. The final SbD documentation required includes the following:

1. Final written responses for all SbD requirements in the SbD checklist, on compliance to the SbD clauses
2. Design document references (including design document file name & section #) in the SbD checklist for all relevant SbD clauses
3. Screenshot evidence on compliance to the SbD checklist for all relevant SbD clauses
4. Uploading of all relevant documentation into the assigned Keppel SbD evidence SharePoint folder		N.A.1. Completed SbD Checklist (including all relevant screenshots)
2. Relevant document uploaded to the Keppel SbD folder
3. Sign-off of completion of SbD assessment.
61
58System DisposalAll Highly Confidential Keppel data, Confidential Keppel data, and Personal Identifiable Information (PII) shall be securely disposed of when the System is decommissioned / no longer in use.N.A.Sensitive data disposal process flow details, as part of the System operations runbook (or equivalent document)
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100