How to Comply With CPS 234

Last updated by Abi Tyas Tunggal on February 13, 2020

scroll down

Prudential Standard CPS 234 Information Security (CPS 234) is an APRA prudential standard.

Australian Prudential Regulation Authority’s (APRA) mission is to establish and enforce prudential standards designed to ensure that, under all reasonable circumstances, financial promises made by its regulated entities are met within a stable, efficient, and competitive financial services sector.

APRA Prudential Standard CPS 234 is one such standard aiming to ensure that an APRA-regulated entity takes measures to be resilient against information security incidents (including cyber-attacks) by maintaining an information security capability commensurate with information security vulnerabilities and threats.

The goal is to minimise the likelihood and impact of information security incidents on the confidentiality, integrity or availability of information assets, including those managed by related parties or third-party service providers by introducing security requirements (and testing of the implementation of controls) for information technology assets. 

Table of contents

Why is APRA CPS 234 important?

CPS 234 is important because it is designed to ensure APRA-regulated entities are resilient to cyber-attacks and other security threats. Additionally, it requires that entities respond in a timely manner should a notifiable data breach or other security incident occur. 

Cyber-attacks are increasing in frequency, sophistication and impact, with perpetrators continually refining their efforts to compromise systems, networks and information. 

Financial institutions are some of the most prominent targets due to possible financial reward (APRA currently supervises institutions holding $6.5 trillion in assets) and access to the personally identifiable information (PII) and protected health information (PHI) that they hold on Australian citizens.

An accelerant to this trend is the increasing use of technology and third-party vendors by superannuation, banking and insurance companies who want to improve customer experience and drive operational efficiencies.  

Consequently, stakeholders including Boards of directors, senior management, shareholders, customers, and regulators have heightened expectations for the effective safeguarding of information assets underpinned by a culture that promotes information security. 

CPS 234 aims to reduce cyber risk and improve cybersecurity by requiring that APRA-regulated entities maintain an information security capability commensurate with their information security vulnerabilities and threats, and employ vendor risk management practices to reduce the likelihood and impact of incidents involving related or third-parties.  

Who needs to comply with CPS 234?

CPS 234 applies to all APRA-regulated entities namely:

  • Authorised deposit-taking institutions (ADIs), including foreign ADIs, and non-operating holding companies authorised under the Banking Act
  • General insurers, including Category C insurers, non-operating holding companies authorised under the Insurance Act, and parent entities of Level 2 insurance groups
  • Life companies, including friendly societies, eligible foreign life insurance companies and non-operating holding companies registered under the Life Insurance Act
  • Private health insurers registered under the PHIPS Act
  • RSE licensees under the SIS Act in respect to their business operations

Additionally, where an APRA-regulated entity's information assets are managed by a third-party, the requirements in CPS 234 also apply to those information assets.

Who is responsible for CPS 234 compliance?

The Board of an APRA-regulated entity is ultimately responsible for CPS 234 compliance. The Board must ensure that the entity maintains information security in a manner commensurate with the size and extent of threats to its information assets, and which enables the continued sound operation of the entity.

That said, the Board can delegate security roles and responsibilities to Board sub-committees, management committees or individuals. As long as the Board can clearly outline how it expects to be engaged with respect to information security, including escalation of risks, issues and reporting.  

Additionally, entities must have clearly defined information security-related roles and responsibilities of the Board, senior management, governing bodies and individuals with responsibility for decision-making, approval, oversight, operations and other information security functions.

This is typically achieved through a combination of role statements, policy statements, reporting lines and charters of governing bodies. Common governing bodies and individuals with decision-making, approval, oversight, operations and other information security roles and responsibilities include:

  • Information security steering/oversight committee
  • Risk management committee (Board and management levels)
  • Board audit committee
  • Executive management committee
  • Chief information Officer (CIO)
  • Chief Information Security Officer (CISO)
  • IT Manager
  • IT Security Manager
  • Information security operations/administration staff
  • Management (business and IT)

These committees and individuals are typically located in separate business units, within the IT function, and within related and third-parties. This can result in a lack of ownership, unclear accountabilities, ineffective oversight and fragmentation of practices. 

To address these issues, clear delineation of the responsibilities of each area and compensating measures must be employed.

Additionally, the Board, governing bodies and individuals should define their information requirements (e.g. schedule, format, scope and content) to ensure they are provided with sufficient and timely information to effectively perform their roles and responsibilities. 

This should include both quantitative and qualitative content. For non-technical audiences, technical information and metrics should be supplemented with appropriate thematic analysis and commentary on business implications. 

This should be supported by defined escalation paths and thresholds, alongside a process to periodically review the audience relevance and fitness for use.  

For additional guidance beyond this guide, we recommend reading Prudential Practice Guide CPG 234 Information Security.  

What are the key requirements of CPS 234?

CPS 234 requires APRA-regulated entities to:

  • Clearly define the information security-related roles and responsibilities of the Board, senior management, governing bodies and individuals
  • Maintain an information security capability commensurate with the size and extent of threats to its information assets, and which enables the continued sound operation of the entity
  • Implement controls to protect its information assets commensurate with the criticality and sensitivity of those information assets, and undertake systematic testing and assurance regarding the effectiveness of those controls
  • Notify APRA of material information security incidents

These key requirements can be broken down further into eight categories, namely:

  1. Information security capability
  2. Policy framework
  3. Information assets identification and classification
  4. Implementation of information security controls
  5. Incident management
  6. Testing control effectiveness
  7. Internal audit
  8. APRA notification

What are CPS 234's information security capability requirements?

CPS 234 requires APRA-regulated entities to:

  • Maintain an information security capability commensurate with the size and extent of threats to its information assets, which enables the continued sound operation of the entity
  • Assess the information security capabilities of related or third-parties who manage information assets on behalf of the entity, commensurate with the potential consequences of an information security incident affecting those assets
  • Actively maintain its information security capability with respect to changes in vulnerabilities and threats, including those resulting from changes to information assets or business environment

To meet these requirements, APRA-regulated entities would typically review the adequacy of resourcing, including funding and staffing, timely access to necessary skill sets and the comprehensiveness of the control environment.

Typical controls may include:

  • Vulnerability and threat management, including situational awareness and intelligence
  • Information security operations and administration
  • Secure design, architecture and consultation
  • Security testing, including penetration testing
  • Information security reporting and analytics
  • Incident detection and response, including recovery, notification and communication
  • Information security investigation, including preservation of evidence and forensic analysis
  • Information security assurance

Additionally, entities must also understand the sufficiency of resources, skills and controls of third-parties and related parties, including the consideration of sub-contracting and on-sourcing arrangements (fourth-party risk). 

This can be achieved through a combination of interview, service reporting, control testing, certifications, attestations (e.g. SOC 2), referrals and independent assurance assessments. 

As CPS 234 requires entities to actively maintain their information security capability, entities should adopt an adaptive and forward-looking approach including ongoing investment in resources, skills and controls. This could be informed by existing and emerging information security vulnerabilities and threats, contemporary industry practices, information security incidents (internal and external), and known information security issues. 

What are CPS 234's information security policy requirements?

Under CPS 234, APRA-regulated entities are required to maintain an information security policy framework commensurate to their exposure to vulnerabilities and threats. This policy should provide direction on the responsibilities of all parties who have an obligation to maintain information security, including governing bodies, staff, contractors, consultants, related parties, third-parties and customers.

Typically this framework is structured as a hierarchy, with higher level policies supported by underlying standards, guidelines and procedures. Common areas addressed in the policy framework include:

  • Identification, authorisation and granting of access to information assets (access control)
  • Lifecycle management ensures information security requirements are considered at each stage, from palling and acquisition through to decommissioning and destruction
  • Management of information security technology solutions including firewalls, antimalware software, intrusion detection/prevention software, cryptographic systems and monitoring/log analysis tools
  • Definition of an overarching information security architecture outlining the approach for designing the IT environment from a security perspective
  • Monitoring and incident management to address the identification and classification of incidents, reporting and escalation guidelines, preservation of evidence and the investigation process
  • Expectations with respect to the maintenance of information security when using third-parties and related parties
  • Acceptable usage of information assets that define responsibilities of end-users including staff, third-parties, related parties and customers
  • Recruitment and vetting of staff and contractors
  • Information security roles and responsibilities
  • Physical and environmental controls
  • Mechanisms to assess compliance with, and ongoing effectiveness of, the information security policy framework. 

This policy framework would typically be consistent with other entity frameworks such as risk management, service provider management and project management. 

Additionally, entities should include an exemption policy defining registration, authorisation and duration requirements. This would typically be a register detailing the nature, rationale and expiry date of exemptions. 

This allows entities to review and assess the adequacy of compensating controls both initially and on an ongoing basis.

Finally, the policy should be periodically evaluated to determine its effectiveness and completeness, and adjustments should be made to ensure its continued effectiveness where needed. 

What are CPS 234's information asset identification and classification requirements?

APRA-regulated entities must classify information assets, including those managed by related parties and third-parties by criticality and sensitivity. 

This includes infrastructure, ancillary systems such as environmental control systems and physical access control systems, as well as information assets managed by third-parties and related parties. 

The interrelationships between information assets, including those which are not intrinsically critical or sensitive but could be used to compromise information assets which are critical or sensitive. 

Furthermore, this should reflect the degree to which information security incidents have the potential to affect, financially or non-financially, the entity or the interests of depositors, policyholders, beneficiaries or other customers.

To provide clarity to internal and external stakeholders, entities should maintain a classification methodology that provides context about what constitutes an information assets, granularity considerations and the method for rating criticality and sensitivity. It's important to note that assets may have a different rating for criticality and sensitivity. 

It is up to the entity to determine whether to assess information assets at a granular level or an aggregated level on a case by case basis. That said, where an entity has chosen to aggregate a number of underlying components into a single assets, the criticality and sensitivity rating for that asset would typically inherit the criticality and sensitivity rating of the constituent components with the highest rating. 

To assist with this, entities generally employ an information asset inventory repository such as a configuration management database (CMBD) to registry and map interrelationships to other assets.

Finally, it is common for entities to leverage their existing business continuity impact analyses to assess criticality and other processes to assess sensitivity. 

What are CPS 234's information security control requirements?

Under CPS 234, APRA-regulated entities must implement information security controls to protect information assets, including those managed by related or third-parties, in a timely manner and commensurate with:

  • Existing and emerging vulnerabilities and threats to critical and sensitive information assets
  • Lifecycle stage of the information assets
  • Potential consequences of an information security incident

Vulnerabilities and threats controls

APRA-regulated entities should ensure existing and emerging security vulnerabilities and threats, especially those pertaining to critical and sensitive information assets, are identified, assessed and remediated in a timely manner.  

This includes those which are not critical or sensitive but could be used to expose critical or sensitive information assets. 

To do this, entities typically:

  • Implement mechanisms that access and analyses threat intelligence feeds regarding vulnerabilities, threats, methods of attack and countermeasures
  • Engage with stakeholders (including Government, industry peers and customers) regarding threats and countermeasures
  • Develop tactical and strategic remediation activities commensurate with the threat
  • Implement mechanisms to disrupt the transitions between phases of attack

An important but often overlooked aspect of vulnerability management is minimising vulnerabilities while maintaining supportability. Many exploitable vulnerabilities arise from hardware and software which is outdated or has limited or no support (whether managed in-house or by a third-party or related party).

A well known example is the Eternal Blue zero-day exploit that resulted in the spread of the WannaCry ransomware worm.

To reduce this risk, entities should decommission systems:

  • That cannot be updated as new security vulnerabilities or threats are identified
  • Where the use of mitigating controls, such as segregation, is not an option

When considering the implementation of new technology, entities should only authorise its use in a production environment when the technology has:

  • A generally agreed set of industry-accepted controls to manage its security
  • Compensating controls sufficient to reduce residual risk with their risk appetite

To facilitate this, many entities develop a technology authorisation process and maintain an approved technology register. 

Lifecycle management controls

This generally means allocating responsibility and accountability of an information asset to an information asset owner, typically an individual location within the business function most dependent on the asset. 

Planning and design controls are the first phase of the information asset lifecycle, typically in place to ensure information security is incorporated from the beginning and typically comply with the entity's information security policy framework.

To prevent the introduction of new information assets compromising existing assets, acquisition and implementation controls are typically in place. Ongoing support and maintenance controls are typically in place to ensure assets continue to meet information security requirements, such as:

  • Change management: Information security is part of change management processes and asset inventory is kept up-to-date
  • Configuration management: The configuration of information assets minimises vulnerabilities and is defined, assessed, registered, maintained, applied constantly, and where necessary, updated to mitigate new vulnerabilities and threats as they are discovered
  • Deployment and environment management: Development, test, and production environments are segregated and segregation of duties is enforced
  • Access management: Only authorised users, software, and hardware are able to access sensitive asset
  • Hardware and software assets: Appropriate authorisation is used to prevent privilege escalation attacks and security compromises from unauthorised hardware and software assets 
  • Network design: Only authorised network traffic flows, reducing the impact of security compromises
  • Vulnerability management: Security vulnerabilities are identified and addressed in a timely manner
  • Patch management: The assessment and application of patches and other updates for known vulnerabilities, like those listed on CVE, are applied in a timely manner
  • Service level agreements: Help monitor, manage and align information security with business objectives 
  • Continuous monitoring: For the timely detection of compromises to information security
  • Response: Information security incidents are responded to and feedback mechanisms are in place to address control deficiencies
  • Capacity and performance management: Ensures availability is not compromised by current or projected business volume
  • Service provider management: Ensures related and third-parties meet the entity's information security requirements 

Finally, decommissioning and destruction controls ensure information security is not compromised when assets reach the end of their life. Controls include archiving strategies and secure data deletion of sensitive information prior to disposal of physical assets.  

As with other information security practices, entities should regularly assess the completeness of their controls by comparing themselves to peers and contemporary industry practices.

Lifecycle management controls are particularly important for end-user developed/configured software which has the purpose of automating day-to-day business processes or facilitating decision-making. As such, entities must introduce processes to identify and classify end-user developed/configure software and assess risk exposures. 

Physical and environmental controls

The absence of physical and environmental controls can compromise the effectiveness of otherwise well-informed information security controls. As such, APRA-regulated entities typically have the following physical and environmental controls in place:

  • Location and building facilities that provide protection from natural and man-made threats, such as diversity of access to key utilities like power and Internet, as well as fall-back mechanisms in case of failure (e.g. generators and wireless hotspots) 
  • Physical access controls that protect the site perimeter, building data room and computing racks, such as gates, locks and procedures for granting and reviewing access by staff, third-party providers and visitors
  • Environmental controls such as ventilation, air conditioning and fire suppression systems
  • Monitoring and alert mechanisms that detect information security incidents where physical and environmental controls failed, such as sensors/alarms for temperature, humidity, water, smoke, unauthorised access and service availability alerts

Change management controls

Common change management controls include:

  • Security testing to identify vulnerabilities and confirm information security requirements have been met
  • Approval of changes prior to deployment into production
  • Segregation of duties between personnel who undertake a change and those deploying the change
  • Changes are developed and verified in a non-production environment to avoid compromise
  • Information security requirements are validated prior to deployment
  • Sensitive production data is desensitised when used for development and testing purposes

Software security controls

APRA-regulated entities typically implement secure software development and acquisition techniques to ensure software:

  • Functions as intended regardless of unforeseen circumstances
  • Has a reduced propensity to be misused intentionally or accidentally 
  • Complies with the entity's information security policy framework

Data leakage controls

APRA-regulated entities typically have data leakage controls commensurate with the sensitivity of the data including:

  • Authorisation, registration, and regular review of users and associated transfer mechanisms and devices including printers, portable storage devices, portable computing devices, electronic transfer mechanisms and conferencing equipment
  • Appropriate blocking, filtering and monitoring of electronic transfer mechanisms, websites and printing
  • Increasing scrutiny of users with higher levels of access
  • Appropriate encryption, cleansing and auditing of devices
  • Monitoring for unauthorised software and hardware (e.g. spyware, password cracking software, wireless access points)
  • Appropriate removal of sensitive data after recovery tests are finished

In short, access to sensitive data (e.g. customer databases or intellectual property) should be highly restricted to reduce the risk of data leaks.

Common targets include:

Cryptographic controls

Cryptographic techniques should be used as a form of access control to sensitive data in storage and in transit, with the strength of encryption commensurate with the sensitivity and criticality of the data and supplementary or compensating controls.

In general, an end-to-end approach should be used where encryption is applied from the point of entry to the final destination to minimise the risk of exposure.

Technology controls

Where appropriate, technology controls such as firewalls, network access control, intrusion detection/prevention devices, anti-malware, encryption and monitoring or log analysis tools should be deployed. 

How reliant entities can be on technology solutions depends on:

  • Guidelines outlining when specific technology solutions should be used 
  • Standards documenting the detailed objectives and requirements of individual technology solutions
  • Authorisation of individuals who can make changes to technology solutions, taking into account segregation of duties
  • Regular assessment of a specific technology solution's configuration, continued effectiveness and identification of any unauthorised access or modification
  • Periodic review of industry practice and benchmarking against peers
  • Detection techniques deployed to provide an alert if the technology solution is not working as designed

Third-party and related parties controls

APRA-regulated entities must evaluate the design of information security controls of third-parties and related parties. 

This can be achieved through a combination of interview, survey, control testing, certifications, contractual review, attestations and independent assurance assessments. 

Once controls are identified, they should be compared to common industry controls, the entity's internal controls and the information assets involved.

Additionally, the entity should understand whether sub-contracting or on-sourcing agreements are permissible within the agreements and if so, awareness of changes to the services they outsource is needed.

Typically, information security considerations should be captured as contractual obligations with oversight agreements. 

Minimising consequences of information security incidents

APRA-regulated entities should consider low likelihood, extreme impact (financial or non-financial) events that could threaten their ongoing ability to meet their obligations, such as:

  • Malicious acts by an insider with high privilege, potentially involving collusion with internal or external parties
  • Deletion or corruption of production and backup data, either through malicious intent, user error or system malfunction
  • Loss of, or unauthorised access to, encryption keys for extremely critical or sensitive information assets

Understanding these plausible worst case scenarios can help entities identify and implement additional controls to prevent or reduce the impact of such events.

What are CPS 234's incident management requirements?

Under CPS 234, APRA-regulated entities must have robust mechanisms in place to detect and respond to information security incidents in a timely manner.

Detection mechanisms typically include scanning, sensing, monitoring and logging solutions. 

The strength and nature of these controls will depend on the impact of a potential security incident, typically covering a broad set of events, ranging from physical hardware to higher order business activities like payments and changes to user access. 

Common techniques include:

  • Network and user profiling to baseline normal behaviour
  • Scanning for unauthorised hardware, software and changes to configurations
  • Sensors that provide an alert when a measure breaches a defined threshold (e.g. network activity)
  • Logging and alerting of access to sensitive data or unsuccessful login attempts
  • Increasing monitoring for users with higher levels of access 

There should be a clear allocation of responsibilities for monitoring processes with appropriate tools in place for timely detection. 

Additionally, entities should maintain incident response plans to respond to information security incidents that could plausibly occur, including mechanisms for:

  • Managing all relevant stages of an incident, from detection to post-incident review
  • Escalation and reporting to the Board, other governing bodies and individuals responsible for information security incident management and oversight, as appropriate
  • Annually review and test information security response plans to ensure they remain effective and fit-for-purpose

Common information security incidents include:

  • Malware infections (e.g. virus or ransomware)
  • Data breaches (customer or internal data)
  • Compromise of staff or customer credentials (e.g. as the result of email spoofing, phishing or spear phishing)
  • Denial of service attacks
  • Website defacement
  • Privilege escalation attacks

The level of detail of response plans should be sufficient to minimise the amount of decision-making required, provide clarity regarding roles and responsibilities, and provide mechanisms for managing all relevant stages of an incident including:

  • Detection of an information security event through the use of automated sensors and manual review
  • Identification and analysis to determine if it is an incident or event
  • Escalation to ensure decision-makers are aware of the incident and can trigger incident response processes
  • Containment to minimise damage caused and potential for future damage
  • Eradication of the source of the compromise (typically malware)
  • Response and recovery steps to return to business-as-usual
  • Post-incident analysis and review to reduce the risk of similar events in the future

Incident response plans should be reviewed annually and tested to ensure they remain effective and fit-for-purpose.

Additionally, entities should seek to formalise the roles and responsibilities of themselves, third-parties and related parties in situations that require collaboration and coordination between them. 

Finally, entities that place reliance on the information security of related or third-parties should seek evidence of the party's periodic testing of their own incident response plans.

This work can be assisted by business continuity, crisis management, continuity plans and recovery plans.

What are CPS 234's control testing requirements?

Under CPS 234, APRA-regulated entities must test the effectiveness of information security controls through a systematic testing program whose nature and frequency is commensurate with:

  • Rate at which the vulnerabilities and threats change
  • Criticality and sensitivity of the information asset
  • Consequences of an information security incident
  • Risks associated with exposure to environments where the entity is unable to enforce its information security policies
  • Materiality and frequency of change to information assets 

That said, it is APRA's view that security controls are tested at least annually, or whenever there is a material change to information assets or the business environment, in order to validate controls remain effective. 

It is important that success criteria for tests are clearly defined, including the circumstances under which re-testing would be required. Test results should be escalated and reported to the Board or senior management, with associated follow-up actions formally tracked and reported in a timely manner.

Finally, testing should be conducted by appropriately skilled and functionally independent specialists who can provide sufficiently bias-free assessment of controls. 

What are CPS 234's internal audit requirements?

Internal audit is an important vehicle by which the Board can gain assurance that information security is maintained. 

This assurance is generally achieved through the inclusion of information security within the entity's internal audit activities and a review of the design and operating effectiveness of information security controls, including those maintained by related and third-parties.

Information security control assurance must be provided by personnel appropriately skilled in providing such assurance. 

Additionally, the internal audit function must assess the information security control assurance provided by related or third-parties where:

  • An information security incident affecting information assets has the potential to materially affect, financially or non-financially, the entity or the interests of depositors, policyholders, beneficiaries or other customers
  • Internal audit intends to rely on the information security control assurance provided by the related party or third-party

If the assessment identifies deficiencies or no assurance is available, the issue is typically raised with the Board for consideration.

When must APRA be notified under CPS 234?

APRA must be notified as soon as possible and no later than 72 hours after an entity becomes aware of an information security incident that:

  • materially affected, or had the potential to materially affect, financially or non-financially, the entity or interests of depositors, policyholders, beneficiaries or other customers
  • has been notified to other regulators in Australia or other jurisdictions

APRA expects the following information to be provided:

  • Name of the APRA-regulated entity
  • Date and time/period of the incident
  • Date and time when the incident was assessed as material
  • Incident type
  • Incident description
  • Current status of incident
  • Mitigation actions taken or planned (where available)

Additionally, APRA must be notified as soon as possible and no later than 10 business days after an entity becomes aware of a material information security control weakness, which the entity does not expect to remediate in a timely manner. APRA expects the following information to be provided: 

  • Name of the APRA-regulated entity
  • Date and time when the control weakness was assessed as material
  • Control weakness description
  • Current status of control weakness
  • Mitigation actions taken or planned 

These material control weaknesses can be identified through control testing, assurance activities, information security incidents (external or internal), vulnerability notification by software and hardware vendors, and other forms of notification by related or third-parties. 

How UpGuard can help you comply with CPS 234 

Companies like Bupa, IAG, First State Super, and Xinja use UpGuard's software to measure their vendors' security posture, prevent data breaches and to help with CPS 234 compliance.

UpGuard Vendor Risk can minimize the amount of time your organization spends assessing related and third-party information security controls by automating vendor questionnaires and providing vendor questionnaire templates that map to CPS 234 requirements.

We can help you continuously monitor your vendors' external security controls and provide an unbiased security rating. 

Security ratings are based on objective, externally observable, continuously available and verifiable information.

UpGuard is one of the most popular security ratings platforms. We generated our ratings through proprietary algorithms that take in and analyze trusted commercial and open-source threat feeds, and non-intrusive data collection methods to quantitatively evaluate cyber risk.

With UpGuard, an organization's security rating can range from 0 to 950 and is comprised of a weighted average of the risk rating of all their underlying domains in addition to the ratings of their vendors.

The lower the rating, the more severe the risks the organization is exposed to. 

Inversely, the higher the rating the better their security practices and the lower chance they will expose sensitive information.

We base our ratings on the analysis of 70+ vectors including:

This has the added benefit of allowing you to instantly benchmark the performance of your current and potential vendors against their industry. 

For the assessment of your own information security controls, UpGuard BreachSight can monitor your organization for 70+ security controls providing a simple, easy-to-understand cyber security ratings and automatically detect leaked credentials and data exposures in S3 buckets, Rsync servers, GitHub repos and more.

The major difference between UpGuard and other security ratings vendors is that there is very public evidence of our expertise in preventing data breaches and data leaks

Our expertise has been featured in the likes of The New York Times, The Wall Street Journal, Bloomberg, The Washington Post, Forbes, Reuters and TechCrunch.

And you can read more about what our customers are saying on Gartner reviews.

If you'd like to see your organization's security rating, click here to request your free Cyber Security Rating.

Book a demo of the UpGuard platform today.


Related posts

Learn more about the latest issues in cybersecurity