SaaS Cloud Security Standards

Project Name/Id <Project Name>
Vendor
<Vendor Name>
Cloud Security Requirements

The requirements are logically broken into the below Domains that map to security arc
If the SaaS application uses a standard TCCC approved integration pattern for authentication / authorization
(e.g. SAML 2.0 via Azure AD or privileged User management via CyberArk) certain requirements are not
applicable as these would be covered by the standard integration pattern. Check individual requirements for
further information.
ame>
ame>
ements
hat map to security architecture
authentication / authorization
tain requirements are not
ck individual requirements for
This tab to be com
** If the SaaS application uses a standard TCCC approved integration pattern for authentication / authorization (e.g. SAML 2.0 via Azure AD or privileged
policies for mor
MSR Ref.No. Domain Control Area
CR-V.01 4. Cryptography Encryption
CV-V.06 4. Cryptography Encrypt in transit
GRC-V.01 1. Governance, Risk, & Data Governance

Compliance
GRC-V.02 1. Governance, Risk, & Data Governance
Compliance
GRC-V.03 1. Governance, Risk, & Information Security

Compliance
GRC-V.04 1. Governance, Risk, & Release Management

Compliance
GRC-V.05 1. Governance, Risk, & Release Management

Compliance
GRC-V.06 1. Governance, Risk, & Resiliency

Compliance
GRC-V.07 1. Governance, Risk, & Compliance

Compliance
Compliance

Compliance
GRC-V.09 1. Governance, Risk, & End of life process

Compliance management
GRC-V.10 1. Governance, Risk, & Auditing

Compliance
IAM-V.01 2. Identity & Access User Access

Management Authentication

Management Authorization



IAM-V.06 2. Identity & Access User Access Reviews

Management
IAM-V.06 2. Identity & Access User Access Reviews
Management
IAM-V.07 2. Identity & Access Credential Lifecycle /

Management Provision
Management
IAM-V.08 2. Identity & Access Audit Logging /

Management Intrusion Detection



Management

Management
IAM-V.13 2. Identity & Access Production access

Management
IAM-V.14 2. Identity & Access Entitlements

Management
IAM-V.15 2. Identity & Access Privilege mgmt

Management
IAM-V.16 2. Identity & Access Inventory

Management
IAM-V.17 2. Identity & Access Credentials

Management
SD-V.01 6. Solution Development Network Security

SD-V.02 6. Solution Development Network Security
SO-V.01 8. Security Operations Incident

Management
SO-V.02 8. Security Operations Information Security -

Management
Program
SO-V.03 8. Security Operations Information Security -

Management
Program
SO-V.04 8. Security Operations Audit Logging /
Intrusion Detection
SO-V.05 8. Security Operations Incident

Management
TA-V.01 7. Training and Awareness Management

Oversight
VTM-V.01 5. Vulnerability and Threat Vulnerability / Patch

Management Management
VTM-V.02 5. Vulnerability and Threat Anti-Virus / Malicious

Management Software
VTM-V.03 5. Vulnerability and Threat Application Security

Management

Highly Restricted and S
Applications utilizing Highly Restricted data must comply with the
MSR Ref.No. Domain Control Area
IAM-V- 2. Identity & Access Segregation of Duties

HRD.01 Management
IAM-V- 2. Identity & Access User Access

HRD.02 Management Authentication
AM-V- 9.Asset Management Information Security

HRD.01
CR-V-HRD.01 4. Cryptography Encryption
CR-V-HRD.02 4. Cryptography Key Management
VTM-V- 5. Vulnerability and Threat Anti-Virus / Malicious

HRD.01 Management Software
VTM-V- 5. Vulnerability and Threat Vulnerability / Patch
HRD.02 Management Management
VTM-V- 5. Vulnerability and Threat Vulnerability / Patch

HRD.03 Management Management
SO-V-HRD.01 8. Security Operations Logging and

Monitoring
SD-V-HRD.01 6. Solution Development Sensitive System

Protection
SO-V-HRD.02 8. Security Operations Incident response
Incident Response
Legal Preparation
This tab to be completed by vendor
pproved integration pattern for authentication / authorization (e.g. SAML 2.0 via Azure AD or privileged User management via CyberArk) certain requirements are not app
policies for more information.
Control Specification CID
CR-V.01.1
For data in transit, all network communication must be encrypted using industry
standards.
Note - Please provide supporting documentation defining encryption standards
and technologies.
CR-V.02.1
CR-V.02.2
All data volume/storage must be encrypted to prevent outside snooping in
addition to preventing unauthorized access to data in the multi-tenant
environment. CR-V.02.3
CR-V.03.1
**User IDs and passwords must be transmitted in an encrypted format and
passwords must be stored in an encrypted format per the current Technical
Security Baseline standards (IPP 9.2.4.4). CR-V.03.2
Note - Please see the instruction section above for more details.
CR-V.04.1
Policies and procedures shall be established and mechanisms implemented for

the secure disposal and complete removal of data from all storage media,
ensuring data is not recoverable by any computer forensic means. This provides CR-V.04.2
assurance of secure data disposal when the storage is decommissioned or when
the contract between the parties end. For example, destroying the key in a multi-
tenant environment.
CR-V.04.3
Data traversing public networks shall be encrypted per the Industry Standard, CR-V.05.1
protected from fraudulent activity, and unauthorized disclosure or modification
in such a manner to prevent compromising of data.
Personal data must be transmitted using firm approved encrypted systems and CV-V.06.1
must not be transmitted via e-mail.
GRC-V.01.1
GRC-V.01.2
Polices and procedures shall be established for labeling, handling, storing,
transmitting, retention/disposal, and security of TCCC data and objects which
contain data, per the TCCC Information Classification Standard and Protection
Measures. Mechanisms for label inheritance shall be implemented for objects GRC-V.01.3
that act as aggregate containers for data.
transmitting, retention/disposal, and security of TCCC data and objects which
contain data, per the TCCC Information Classification Standard and Protection
Measures. Mechanisms for label inheritance shall be implemented for objects
that act as aggregate containers for data.
GRC-V.01.4
GRC-V.02.1
Security mechanisms and policies shall be established and implemented to

prevent data leak in transit and data at rest leakage.
GRC-V.03.1
Policies, process, and procedures shall be implemented to enforce and ensure
proper segregation of duties. In those events where user-role conflict of interest
constraint exist, technical controls shall be in place to mitigate any risks arising
from unauthorized or unintentional modification or misuse of the organization's
information assets.
GRC-V.04.1
The development of all software shall be supervised and monitored by the

organization and must include:
• security requirements GRC-V.04.2
• independent security review of the environment
by a certified individual
• code reviews
Quality monitoring, evaluation, and acceptance criteria for information systems, GRC-V.05.3
upgrades, and new versions shall be established and documented.
GRC-V.05.4
GRC-V.05.1
Changes to the production environment shall be documented, tested, and
approved prior to implementation. Production software and hardware changes
may include applications, systems, databases, and network devices requiring
patches, service packs, and other updates and modifications.
A consistent, unified framework for business continuity planning, disaster GRC-V.06.1

recovery, plan development, and appropriate communications shall be
established, documented, and adopted to ensure all business continuity plans
are consistent to protect against natural and man-made disasters (e.g. fire, flood,
earthquake, war, volcanic activity, biological hazard, civil unrest, mudslide,
tectonic activity, utility services outages, etc.).
GRC-V.06.2
Business continuity plans shall be subject to test at least annually or upon
significant organizational or environmental changes to ensure continuing
effectiveness.
GRC-V.06.3
Note - Supporting documentation required: DR/Business Continuity Plans
GRC-V.06.4
GRC-V.07.1
Aligned with the enterprise-wide framework, independent reviews or formal risk

assessments shall be performed at least annually, or at planned intervals,
determining the likelihood and impact of all identified risks, using qualitative
and/or quantitative methods to ensure the organization is compliant with
policies, procedures, standards, and applicable regulatory requirements (i.e.,
internal/external audits, certifications, vulnerability, and penetration testing).
Note - Supporting documentation required: Independent Third-Party

GRC-V.07.2
Aligned with the enterprise-wide framework, independent reviews or formal risk
assessments shall be performed at least annually, or at planned intervals,
determining the likelihood and impact of all identified risks, using qualitative
and/or quantitative methods to ensure the organization is compliant with GRC-V.07.3
policies, procedures, standards, and applicable regulatory requirements (i.e.,
internal/external audits, certifications, vulnerability, and penetration testing).
Note - Supporting documentation required: Independent Third-Party

Attestation (such as SSAE18/ISAE3402, ISO27001) and Independent Third-Party GRC-V.07.4
Penetration Test Results
GRC-V.07.5
Vendors that are storing, transmitting, and/or processing payment card data (e.g. GRC-V.08.1
full payment card numbers, primary account numbers, etc.) must be in
compliance with the Payment Card Industry (PCI) Data Security Standard (DSS).
Note - Supporting documentation required.

GRC-V.08.2
Ensure processes are in place to transition data from unsupported to supported GRC-V.09.1
systems and applications.
Perform (and document results of) an information audit to determine what GRC-V.10.1
personal data is being stored and/or processed.
Policies and procedures shall be established and measures implemented to IAM-V.01.1

enforce two-factor authentication for privileged account
management/authentication while accessing tenant data/systems.
Systems must be configured to log all successful and unsuccessful login attempts IAM-V.02.1
by accounts with privileged access. (IPP 12.4.1.2) These authentication logs must
be retained for a minimum of 180 days and in accordance with the Company’s
records retention guidelines. (IPP 12.4.2.1)
Systems shall require users to re-authenticate at the time of an attempted IAM-V.03.1

change to authentication information. (IPP 9.4.3.7)
Intended Users shall be presented with a login notice before being given the IAM-V.04.1
opportunity to log onto a System. (IPP 9.4.2.2)
Systems shall be designed to not give any information beyond notification of an IAM-V.05.1
unsuccessful login attempt prior to successful login. (IPP 9.4.2.4)
IAM-V.06.1
**Solution shall support for the TCCC Business Owner to review User access
rights (180 days) and at least every 90 days for privileged access and SOX
relevant information (IPP 9.2.5.1). For access violations identified, remediation
must follow documented access control policies and procedures.
IAM-V.06.2
**Solution shall support for the TCCC Business Owner to review User access
rights (180 days) and at least every 90 days for privileged access and SOX
relevant information (IPP 9.2.5.1). For access violations identified, remediation
must follow documented access control policies and procedures.
IAM-V.06.3
IAM-V.06.4
Systems must support complex and strong passwords, and shall be IAM-V.07.1
communicated to the User in an out-of-band method (e.g., application
passwords can be phoned or mailed to the User, but not provided through the
application interface) (IPP 9.2.4.3). **Solution shall support measures to expire
User passwords no more than 13 months (IPP 19.2.1.3). For access violations
identified, remediation must follow documented access control policies and IAM-V.07.2
procedures
**Newly assigned passwords (e.g., initial, reset, temporary) must be unique,
randomly generated, and expire upon first use or after no more than 7 calendar
days if not used. (IPP 9.2.4.1) IAM-V.07.3
• Solution shall support passwords with a minimum of 12
characters in length and a minimum of 1 alphabetic, 1 numeric,
and 1 symbolic character for Non-Privileged (personal) User
• Solution shall support strong passwords that are a minimum
of 15 characters in length and are
comprised of letters, numbers, and special characters for
Privileged Users and are required to change password every 90 days IAM-V.07.4
(IPP 9.2.3.3)
Audit logs recording privileged User access activities, authorized and IAM-V.08.1
unauthorized access attempts, system exceptions, and information security
events (e.g. source, target, attack type, and payload, for investigation purposes)
shall be retained for 180 days, complying with applicable policies and
regulations. Audit logs shall be reviewed at least daily and event management
tools be implemented to help facilitate timely detection, investigation by root IAM-V.08.2
cause analysis, and response to incidents. Physical and logical User access to
audit logs shall be restricted to authorized personnel.
Audit logs must be integrated with Security Operations/SIEM (Security IAM-V.08.3

Information and Event Management) solution.
IAM-V.08.4
IAM-V.08.5
Security mechanisms and policies shall be established and implemented to IAM-V.09.1

facilitate timely detection and investigation by root cause analysis and incident
responses for file integrity (host) and network intrusion detection (IDS) tools.
Security mechanisms and policies shall be established and implemented to
facilitate timely detection and investigation by root cause analysis and incident
responses for file integrity (host) and network intrusion detection (IDS) tools.
IAM-V.09.2
IAM-V.09.3
Solution shall support measures to strictly limit access to tenant data from non- IAM-V.10.1
authorized or non-enterprise managed devices (e.g., personal desktop
computers or personal mobile devices).
**Solution shall support measure to expire dormant accounts. User accounts IAM-V.11.1
that have not been used within a minimum of 90 days shall be
de-provisioned/expired unless an exception is approved. For access violations
identified, remediation must follow documented access control policies and
procedures.
**Solution shall not support cyclical passwords for User accounts. Where IAM-V.12.1
technically feasible, Systems shall use password history techniques to maintain a
history of User’s passwords and disallow the reuse of passwords in the history
file. (IPP 9.4.3.3)
Access request to systems handling personal data must be approved and IAM-V.13.1
restricted to authorized individuals.
Access to personal data or functionality that process personal data must be IAM-V.14.1
restricted to users or systems with approved entitlements (RBAC).
Entitlements applied to resources handling personal data must be onboarded to IAM-V.15.1

firm approved systems and subject to regular automated and manual review and
automated de-provisioning.
Personal data fields stored in databases and any non-database data stores IAM-V.16.1
containing personal data being used by applications must be registered in a
standard inventory repository.
All credentials used by apps processing personal data must be stored in IAM-V.17.1
centralized TCCC approved credential storage system.
Network environments shall be designed and configured to restrict SD-V.01.1

communications and connections between the tenant environment and vendor
corporate networks and restrict access to the tenant environment from the
vendor network. Vendor's corporate environment needs to be restricted and
managed accordingly.
Network and Solution architecture diagrams must clearly identify high-risk SD-V.02.1
environments and data flows that may have regulatory compliance impacts. All
termination of network encryption shall be clearly identified. These architecture
diagrams shall be made available on request.
SD-V.02.2
The service provider shall provide notification to the TCCC Security Operations SO-V.01.1
(KO-CIRT at kocirt@coca-cola.com or +1-404-515-2478, their local help desk,
and the business owner of the data that was protected) for anomalous activity,
identified breaches, and security events. (IPP 10.1.2.12)
Note - Please provide supporting documents describing thresholds for notifying

tenants of security incidents. SO-V.01.2
SO-V.01.3
Vendor should have an Information Security Management Program (ISMP) SO-V.02.1

developed, documented, approved, and implemented that includes
administrative, technical, and physical safeguards to protect assets and data
from loss, misuse, unauthorized access, disclosure, alteration, and destruction.
The security program should address, but not be limited to, the following areas
insofar as they relate to the characteristics of the business:
• Risk management SO-V.02.2
• Security policy
• Organization of information security
• Asset management
• Human resources security
• Physical and environmental security
• Communications and operations management
• Access control
• Information systems acquisition, development, and maintenance
Note - Supporting documentation required.
Information security policy shall be reviewed at quarterly intervals or as a result SO-V.03.1

of changes to the organization to ensure its continuing effectiveness and
accuracy.
SO-V.03.2
SO-V.04.1
Network changes, firewall changes, firewall perimeter, user access, changes to

the configuration of OS, malware protection, patch management, and antivirus
log data is maintained for least 180 days within a SIEM (Security Information and
Event Management) solution.
SO-V.05.1
SO-V.05.2
System should log, monitor, and collect relevant security event data, (e.g.,
source, target, attack type, and payload) for investigation purposes.
SO-V.05.3
TA-V.01.1
A security awareness training program shall be in place for all contractors, third-
party users, and employees of the organization and mandated when appropriate. TA-V.01.2
All individuals with access to organizational data shall receive appropriate
awareness training and regular updates in organizational procedures, process,
and policies relating to their function relative to the organization.
TA-V.01.3
Policies and procedures shall be established and mechanism implemented for VTM-V.01.1
detecting and addressing standard vulnerabilities within the below timeframe
per the Security Patch Management Standard, or similar change management
standard:
Severity 5: 14 days
Severity 4: 30 days
Severity 3: 180 days VTM-V.01.2
Severity 2: Optional
Incase the mentioned timelines are not met, vendors should be able to provide
their agreed upon timelines.
VTM-V.01.3
Note - Please find further details in the severity definition section.
Policies and procedures shall be established and mechanism implemented for VTM-V.02.1
malware protection. Ensure that all anti-malware programs are capable of
detecting, removing, and protecting against all known types of malicious or
unauthorized software with antivirus signature and definition updates at least
every 12 hours. Software must not be more than one major revision behind
current software version.
VTM-V.02.2
Web-facing High Business Impact (HBI) applications, PI, and SPI shall be VTM-V.03.1
protected by a standard WAF (Web Application Firewall).
VTM-V.04.1
Perform periodic scanning of operating systems, databases, and server

applications for vulnerability and configuration compliance using suitable
vulnerability management tools as per the industry standard. Policies and
procedures shall be established and mechanism implemented for maintaining
vulnerability scan results for at least one year and provide, as needed, for audit
and review purposes.
VTM-V.04.2
Perform periodic scanning of operating systems, databases, and server
applications for vulnerability and configuration compliance using suitable
vulnerability management tools as per the industry standard. Policies and VTM-V.04.3
procedures shall be established and mechanism implemented for maintaining
vulnerability scan results for at least one year and provide, as needed, for audit
and review purposes.
VTM-V.04.4
Highly Restricted and SPI Data Requirements
Applications utilizing Highly Restricted data must comply with the below requirements in addition to baseline security requirements
Control Specification CID
For HBI and Highly Restricted data, segregation of duties shall be implemented IAM-V-
and maintained across all infrastructure and application layers e.g., a Server HRD.01.1
Administrator or Host Service Account shall not have privileged access to an
application running on the server. Similarly, an Application Administrator or
Application Service Account shall not have administrative access to the
middleware or server configurations.
Solution shall support measures implemented to enforce strong multifactor IAM-V-

authentication for access to Highly Restricted Data (e.g., RSA Secure ID, PKI HRD.02.1
Certificates, out of band pin comprised of at least 6 digits, etc.). (IPP 9.2.4.2)
Solution shall limit access to TCCC managed devices for High Business Impact AM-V-
Application and Highly Restricted Data. HRD.01.1
CR-V-HRD.01.1
For data in transit, network communication must be encrypted for Highly
Restricted, HBI, and SPI. Highest Level Data Classification requirements must be
adhered to when there are multiple data classifications. All termination of
network encryption shall be clearly identified.
CR-V-HRD.02.1
For SPI, HBI, and Highly Restricted data, all cryptographic keys shall be managed
by TCCC. Policies and procedures shall be established and measures
implemented for segregation of duties between PKI administration and System
Administration.
The TCCC information protection organization shall retain back-up copies of

encryption keys used to protect Highly Restricted information. (IPP 10.1.2.11)
Host/file integrity (protection module) is required for any systems storing and VTM-V-
transmitting Highly Restricted Data to detect any unauthorized changes to data HRD.01.1
or system configuration.
VTM-V-
HRD.02.1
Policies and procedures shall be established and mechanisms implemented for
detecting and addressing High Business Impact and Highly Restricted data
vulnerabilities within the below timeframe per the IRM Security Patch
Management Standards and Policies.
Severity 5: 7 days
Severity 4: 14 days
Severity 3: 90 days
Incase the mentioned timelines are not met, vendors should be able to provide
their agreed upon timelines.
Note - Please find further details in the severity definition section.
VTM-V-
HRD.03.1
VTM-V-
HRD.03.2
VTM-V-
HRD.03.3
For Highly Restricted Data and HBI, vulnerability scanning shall be performed at
least daily within operating systems, databases, and server applications. Scanning
shall include vulnerability and configuration compliance, using the industry
approved vulnerability management tool.
VTM-V-
HRD.03.4
VTM-V-
HRD.03.5
SO-V-HRD.01.1
Continual security monitoring for unauthorized activity and attempted intrusion
is required for HBI and all Systems that process or store Highly Restricted
information using standard TCCC approved technologies (IPS, IDS, anomaly
detection, Security Analytics, etc.). Any attempted intrusion logs shall be sent to
TCCC SOC.
SD-V-HRD.01.1
SD-V-HRD.01.2
Systems and applications classified as Highly Restricted shall have a dedicated
computing environment isolated using physical or logical methods. Logical
methods of isolation shall be based on the Architecture and Technical Security
Baselines identified by Information Technology. (IPP 9.4.6.1)
SD-V-HRD.01.3
SO-V-HRD.02.1
Proper forensic procedures, including chain of custody, are required for the SO-V-HRD.02.2
presentation of evidence to support potential legal action subject to the relevant
jurisdiction after an information security incident. Upon notification, customers
and/or other external business partners impacted by a security breach shall be
given the opportunity to participate, as is legally permissible, in the forensic SO-V-HRD.02.3
investigation.
SO-V-HRD.02.4
completed by vendor
eged User management via CyberArk) certain requirements are not applicable as these would be covered by the standard integration pattern. Refer to TCCC
more information.
Consensus Assessment Answers

Consensus Assessment Questions
Yes No N/A
For data in transit, do you leverage encryption to protect Yes
data during transport across and between networks
instances including services like SSH, HTTPS, etc.?
Do you encrypt data at rest? Yes
Do you segregate multi-tenant data using encryption? Yes
Do you provide native encryption capability for sensitive Yes

data fields? If so, are there any limits on the number of
fields?
Do you have controls in place to ensure User IDs and Yes

passwords are transmitted in an encrypted format?
Are passwords stored in an encrypted or a single, one-way Yes

hash?
Do you support secure deletion (e.g.,

degaussing/cryptographic wiping) of archived and backed-up
data as determined by the tenant?
NA
Can you provide a published procedure for exiting the
service arrangement, including assurance to sanitize all
computing resources of tenant data once a customer has
exited your environment or has vacated a resource?
NA
Do you allow tenants to use their own certificates? Yes
Do you utilize open encryption methodologies any time your

infrastructure components need to communicate with each
other via public networks (e.g., Internet-based replication of
data from one environment to another)?
No
Are TCCC approved technologies used to transfer personal
data? (Other than e-mail)
NA
Are policies and procedures established for labeling,
handling and the security of data and objects that contain
data?
NA
Are mechanisms for label inheritance implemented for
objects that act as aggregate containers for data?
NA
Do you adhere to tenant's retention policy?
NA
If not, please provide your retention policy and secure data
disposal documentation.
NA
Yes
Can you provide a published procedure for security
mechanisms to prevent data leakage in transit and data at
rest leakage upon request?
Can you provide tenants, upon request, documentation on

how you maintain segregation of duties within your cloud
service offering?
NA
Do you use industry standards (Build Security in Maturity Yes
Model [BSIMM] benchmarks, Open Group ACS Trusted
Technology Provider Framework, NIST, etc.) to build in
security for your Systems/Software Development Lifecycle
(SDLC)?
Do you use automated and manual source code analysis Yes

tools to detect security defects in code prior to production?
Do you review your applications for security vulnerabilities Yes

and address any issues prior to deployment to production?
Do you verify that all of your software suppliers adhere to Yes

industry standards for Systems/Software Development
Lifecycle (SDLC) security?
Do you provide tenants with documentation that describes Yes

your production change management procedures and their
roles/rights/responsibilities within it?
Are any of your data centers located in places that have a

high probability/occurrence of high-impact environmental
risks (floods, tornadoes, earthquakes, hurricanes, etc.)?
NA
Do you provide tenants with geographically resilient hosting
options?
NA
Do you provide tenants with infrastructure service failover
capability to other providers?
NA
Are business continuity and disaster recovery plans subject
to test at least annually and upon significant organizational
or environmental changes to ensure continuing
effectiveness?
Do you allow tenants to view your SOC2/ISO 27001 or Yes

similar third-party audit or certification reports?
Do you conduct annual network penetration tests of your
cloud service infrastructure regularly as prescribed by
industry best practices and guidance?
NA
Do you conduct annual application penetration tests of your
cloud infrastructure regularly as prescribed by industry best
practices and guidance?
NA
Do you perform annual audits (internal and external) and are
the results available to tenants upon request?
NA
Are the results of the penetration tests available to tenants
at their request?
NA
Are you storing, transmitting, and/or processing payment
card data on behalf of The Coca-Cola Company? (This could
include hosting infrastructure that is involved in a payment
process.)
NA
If yes, provide the current Attestation of Compliance (AOC)
that is on file with the PCI Council.
NA
Is there a formal process that details the transition of data Yes
from unsupported systems and applications to supported
systems and applications?
Do you conduct information audits to determine what

personal data is being stored/processed and where is it
being stored?
NA
Do you enforce two-factor authentication for privileged
account management/authentication while accessing tenant
data/systems?
NA
Do you retain all logs for all login attempts for a minimum Yes
time period of 90 days or as required by the tenant?
Does the solution provide re-authentication at the time of an Yes

attempted change to authentication information?
Can you provide the capability to present with a login notice Yes
to the intended users before being given the opportunity to
log onto a system?
Do you have controls in place to restrict any information Yes

beyond notification of an unsuccessful login attempt prior to
successful login?
Do you support use of, or integration with, existing Yes

customer-based Single Sign On (SSO) solutions to your
service?
Do you support identity federation standards (SAML 2.0,
SPML, WS-Federation, etc.) as a means of
authenticating/authorizing users?
No
Do you allow tenants to use third-party identity assurance
services?
NA
Do you support tenant's access review policy?
NA
Do you support password (minimum length, age, history, Yes
complexity, and expiration) and account lockout (lockout
threshold, lockout duration) policy enforcement?
Do you allow tenants/customers to define password and Yes

account lockout policies for their accounts?
Yes
Do you support the ability to force password changes upon
first logon?
Do you have mechanisms in place for unlocking accounts

that have been locked out (e.g., self-service via email,
defined challenge questions, manual unlock)?
NA
Are audit logs reviewed on a regular basis for security events
(e.g., with automated tools)?
NA
Is physical and logical User access to audit logs restricted to
authorized personnel?
NA
Do you support integration of audit logs with tenant Security
Operations/SIEM (Security Information and Event
Management) solution?
NA
Are audit logs centrally stored and retained?
NA
Describe how event logs are protected from alteration
including how access to these logs is controlled.
NA
Are file integrity (host) and network intrusion detection (IDS)
tools implemented to help facilitate timely detection,
investigation by root cause analysis, and response to
incidents?
No
Describe the process for investigating all data breaches and
security violation events. Describe the process for informing
TCCC of the breach, root cause analysis, and remediation.
No
Does your logging and monitoring framework allow isolation
of an incident to specific tenants?
No
Are policies and procedures established and measures Yes
implemented to strictly limit access to your sensitive data
and tenant data from portable and mobile devices (e.g.,
laptops, cell phones, and personal digital assistants (PDAs)),
which are generally higher-risk than non-portable devices
(e.g., desktop computers at the provider organization’s
facilities)?
Does the solution support disabling of dormant accounts Yes

(User accounts that have not been used within a minimum
of 90 days)?
Does the solution maintain a password history technique in

order to disallow use of any cyclic passwords?
No
Is there an approval process for access requests to systems
handling personal data?
Na
Is access to systems containing personal data granted using Yes
a role-based criteria?
Are account privileges provisioned and de-provisioned using

TCCC approved manual and automated processes
appropriately?
NA
Is all Personal Data registered in a standard repository?
NA
Are credentials stored in a centralized system that is TCCC
approved?
NA
Do you have the ability to logically segment or encrypt
customer data such that data may be produced for a single
tenant only, without inadvertently accessing another
tenant's data?
NA
Do you logically and/or physically separate tenant systems
from corporate systems?
NA
Are information system documents (e.g., administrator and Yes
User guides, architecture diagrams, etc.) made available to
authorized personnel to ensure configuration, installation,
and operation of the information system?
Have you suffered any security breach in the last 5 years?
NA
Do you make security incident information available to all
affected customers and providers periodically through
electronic methods (e.g., portals)?
NA
In the case of confirmed security incidents targeted at TCCC,
do you provide immediate notification to KO-CIRT?
NA
Do you provide tenants with documentation describing your
Information Security Management Program (ISMP)?
NA
Do you review your Information Security Management
Program (ISMP) at least once a year?
NA
Please provide your Information Security Policy, Privacy
Policy, and other related policies documents.
NA
Do you ensure your providers adhere to your information
security and privacy policies?
NA
Does your security information and event management
(SIEM) system merge data sources (app logs, firewall logs,
IDS logs, physical access logs, etc.) for granular analysis and
alerting?
NA
Do you have a documented security incident response plan?
NA
Do you monitor and quantify the types, volumes, and
impacts on all information security incidents?
NA
Does your incident response plan comply with industry
standards for legally admissible chain-of-custody
management processes and controls?
NA
Are all personnel required to sign NDA or Confidentiality
Agreements as a condition of employment to protect
customer/tenant information?
NA
Do you specifically train your employees, contractors, third-
party users regarding their specific role and the information
security controls they must fulfill?
NA
Are personnel trained and provided with awareness
programs at least once a year?
NA
Do you have a capability to rapidly patch vulnerabilities Yes
across all of your computing devices, applications, and
systems?
Do you have the capability to adhere to the tenant's severity

timeframes outlined in column D?
NA
Will you provide your risk-based systems patching time
frames to your tenants upon request?
NA
Do you have anti-malware programs that support or connect
to your cloud service offerings installed on all of your
systems?
NA
Do you ensure that security threat detection systems using
signatures, lists, or behavioral patterns are updated across
all infrastructure components within industry accepted time
frames?
NA
Do you provide WAF services?
NA
Do you conduct local operating system-layer vulnerability
scans regularly as prescribed by industry best practices?
NA
Do you conduct network-layer vulnerability scans regularly
as prescribed by industry best practices?
NA
Do you conduct application-layer vulnerability scans
regularly as prescribed by industry best practices?
NA
Will you make the results of vulnerability scans available to
tenants at their request?
NA
and SPI Data Requirements
the below requirements in addition to baseline security requirements

Consensus Assessment Questions
Yes No N/A
Do you design and implement controls to mitigate and

contain data security risks through proper separation of
duties, role-based access, and least-privileged access for all
personnel within your supply chain?
NA
Do you support tenant's multifactor authentication (e.g., RSA

Secure ID, PKI Certificates, out of band pin comprised of at
least 6 digits, etc.)?
NA
Do you support access to tenant sensitive data by only
tenant's managed devices?
NA
Do you support end-to-end encryption of tenant's data in

transit across all security zones?
Yes NA
Do you allow your tenant to manage all cryptographic keys
(e.g., data encryption, SSL certificates) for sensitive data?
Yes NA
Do you have controls and processes in place to perform
host/file integrity monitoring for all systems storing and
transmitting sensitive data? NA
Do you have the capability to adhere to the tenant's severity
timeframes, outlined in column D?
NA
Do you conduct daily vulnerability scans at the operating
system layer? NA
Do you conduct daily vulnerability scans at the database

layer?
NA
Do you conduct daily vulnerability scans at the application

layer?
NA
Are your security vulnerability assessment tools approved as

per industry standards?
NA
Do you have external third party services conduct

vulnerability scans and periodic penetration tests on your
applications and networks?
NA
Do you use file integrity (host) and network intrusion
detection (IDS) tools for you SaaS solution to help facilitate
timely detection, investigation by root cause analysis, and
response to incidents?
NA
Can you a provide dedicated computing environment for the
tenant?
NA
Do you provide the logical segregation of tenant data and

the application?
NA
Do you logically and physically segregate production and

non-production environments?
NA
Does your incident response plan comply with industry
standards for legally admissible chain-of-custody
management processes and controls?
NA
Does your incident response capability include the use of
legally admissible forensic data collection and analysis
techniques? NA
Are you capable of supporting litigation holds (freeze of data

from a specific point in time) for a specific tenant without
freezing other tenant data?
NA
Do you enforce and attest to tenant data separation when

producing data in response to legal subpoenas?
NA
overed by the standard integration pattern. Refer to TCCC

Notes/Comments
Refer IDE.PDF Page 556

TLS 1.2 encryption is used for all
communications using the HTTPS protocol.
No Limits on the number of fields
This is on premise solution. So data is

managed by HCCB not stored in aveva
solution

managed by HCCB. No data is managed or
controlled by aveva solution
https://docs.aveva.com/bundle/system-platform-deployment-guide/page/927763.html
System Management Server node

The System Management Server is used to
implement important security measures for

performance.
• Data in use can be protected by enabling
strong user authentication policies and
procedures. Enable Galaxy
security to limit user access to the functions
that each user needs to perform their job.
The use of Named
This is on premise
Credentials within solution.
AVEVA OMI So data is
ViewApps
managed
can enhanceby HCCB. No data
user-based is managed or
or group-based
controlled
security at by
runaveva
time.solution
• Encryption key management and storage:
TLS certificates are stored locally by the
operating system in the
Windows Certificate Store. Keys can be
managed with the Windows Certificate
Manager.

AVEVA ISA Secure SDLA document for your

reference
AVEVA SOC_2_Type_2
AVEVA SOC_2_Type_2
AVEVA SOC_2_Type_2 and AVEVA ISA

Secure SDLA document for your reference
During engineering we will be provided all

the relavent datas
This is on premise solution.
This is onispremise
Solution capablesolution.
of handling DC and DR.
But currently we have considered only
solution
This is onaspremise
Main server. No Our
solution. DR issolution can
considered.
be hosted onHowever we can provided
HCCB infrastrucure thebe
and can
solution for DR and
managed by customer implement using
Virtualization find the below link for your
reference
https://docs.aveva.com/bundle/system-
platform-deployment-guide/page/
341860.html
Find the attachement

However we have proposed on Premise
solution which is not relavent



All the products has Life cycle management

and upgradation plan defined for each
solution in place

We have proposed on Premise solution We
can integrate with Azure AD as
Authentication providers
As we are providing on Premise solution all

the user event are captured in the windows
event logs. Which can be used for audit
trails for user logins
All the Relavent user policies can be used

from AD to control all user access and
permissions

permissions

permissions
Page 578
We have proposed on Premise solution We
can integrate with Azure AD as
Authentication providers
NO

permissions

permissions

permissions
we have proposed on Premise solution.All

the Relavent user policies can be used from
AD to control all user access and
permissions. HCCB IT team should manage
all the required process.
we have proposed on Premise solution. All
we have proposed
permissions. HCCB on Premise
IT team solution.
should manageAll
the Relavent
all the user
required policies can be used from
process.
we have proposed on Premise solution.Not

part of our proposal





All the relavent documents are part of the

solution setup guide
we have proposed on Premise solution.

We can provide the patch management for

all the solutions which are considered in our
scope
we have proposed on Premise solution.This

can be conducted by HCCB


Notes/Comments

all the required process. Our solutions
supports role based access which can be
defined in AD same can be used for
managing the application

we have proposed on Premise
solution.Relavent encryption has been
taken care.

solution.Relavent encryption has been
taken care.
Page 556

we
we have proposed on
have proposed on Premise
Premise solution.
solution.Relavent solution for monitoring
Vulnerability and treat should be managed
by HCCB IT team

by HCCB IT team

by HCCB IT team

by HCCB IT team

by HCCB IT team

by HCCB IT team


SaaS Cloud Security Standards

Uploaded by

Copyright:

Available Formats

You might also like

SaaS Cloud Security Standards

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SaaS Cloud Security Standards

Uploaded by

Copyright:

Available Formats

Project Name/Id <Project Name>

Cloud Security Requirements

MSR Ref.No. Domain Control Area

CR-V.01 4. Cryptography Encryption

CR-V.02 4. Cryptography Encryption

CR-V.03 4. Cryptography Encryption

CR-V.04 4. Cryptography Encryption

CR-V.05 4. Cryptography Encryption

CV-V.06 4. Cryptography Encrypt in transit

GRC-V.01 1. Governance, Risk, & Data Governance

GRC-V.03 1. Governance, Risk, & Information Security

GRC-V.04 1. Governance, Risk, & Release Management

GRC-V.05 1. Governance, Risk, & Release Management

GRC-V.06 1. Governance, Risk, & Resiliency

GRC-V.07 1. Governance, Risk, & Compliance

GRC-V.08 1. Governance, Risk, & Compliance

GRC-V.09 1. Governance, Risk, & End of life process

GRC-V.10 1. Governance, Risk, & Auditing

IAM-V.01 2. Identity & Access User Access

IAM-V.02 2. Identity & Access User Access

IAM-V.03 2. Identity & Access User Access

IAM-V.04 2. Identity & Access User Access

IAM-V.05 2. Identity & Access User Access

IAM-V.06 2. Identity & Access User Access Reviews

IAM-V.07 2. Identity & Access Credential Lifecycle /

IAM-V.08 2. Identity & Access Audit Logging /

IAM-V.09 2. Identity & Access Audit Logging /

IAM-V.10 2. Identity & Access User Access

IAM-V.11 2. Identity & Access Credential Lifecycle /

IAM-V.12 2. Identity & Access Credential Lifecycle /

IAM-V.13 2. Identity & Access Production access

IAM-V.14 2. Identity & Access Entitlements

IAM-V.15 2. Identity & Access Privilege mgmt

IAM-V.16 2. Identity & Access Inventory

IAM-V.17 2. Identity & Access Credentials

SD-V.01 6. Solution Development Network Security

SO-V.01 8. Security Operations Incident

SO-V.02 8. Security Operations Information Security -

SO-V.03 8. Security Operations Information Security -

SO-V.05 8. Security Operations Incident

TA-V.01 7. Training and Awareness Management

VTM-V.01 5. Vulnerability and Threat Vulnerability / Patch

VTM-V.02 5. Vulnerability and Threat Anti-Virus / Malicious

VTM-V.03 5. Vulnerability and Threat Application Security

VTM-V.04 5. Vulnerability and Threat Vulnerability / Patch

Highly Restricted and S

Applications utilizing Highly Restricted data must comply with the

MSR Ref.No. Domain Control Area

IAM-V- 2. Identity & Access Segregation of Duties

IAM-V- 2. Identity & Access User Access

AM-V- 9.Asset Management Information Security

CR-V-HRD.01 4. Cryptography Encryption

CR-V-HRD.02 4. Cryptography Key Management

VTM-V- 5. Vulnerability and Threat Anti-Virus / Malicious

VTM-V- 5. Vulnerability and Threat Vulnerability / Patch

SO-V-HRD.01 8. Security Operations Logging and

SD-V-HRD.01 6. Solution Development Sensitive System

Control Specification CID