Skip to end of metadata
Go to start of metadata


Queen's University Cloud Services Policy


Definition of Cloud Service - roughly, information processing service operated by an independent organization off university property.


All Cloud Services must be assessed for security and privacy risks by the ATO process before usage agreements are concluded. This applies to any of the usage patterns, such as Software as a service, Platform as a service, Infrastructure as a service. The depth of assessment will vary depending on the classification, quantity, and usage of the information involved.


possible exception for individual services not containing University Records or personal information about other people


Every Cloud Service must have a designated Service Owner. The Service Owner must be at a level in the University that is approved by the Trustees to accept risk of failures or breaches. Typically this will be a department head or above. The Service Owner is responsible for

  • maintaining the contract and service payments
  • administering the service for the University
  • contingency preparation for temporary and premanent unavailbility of the service
  • safeguarding of information stored in the service
  • destruction of data on approved schedule

These responsibilities may be delegated, but the Owner remains responsible.


The Cloud Service must be registered in the inventory maintained by Information Technology Services. The tracked information shall include:

  • Name and type of SaaS service
  • Owner (and other roles if used)
  • Data sensitivity or significance (such as confidentiality, integrity, availability and regulatory compliance)
  • additional information depending on the nature of the service
  • security and privacy risk assessment
  • SPRA renewal schedule
  • SPRA usage limitations



Working notes



No effective governance is possible without some degree of policy to set the rules and provide a basis for enforcement. At a minimum, CIOs should establish three basic SaaS control policies:

1. There should be no use of any SaaS service without approval through a defined process.

This does not necessarily mean that IT can veto every request to use SaaS, but instead the CIO must work with business stakeholders to create a process for how IT and business can work together in acquiring new SaaS capabilities (see "Sourcing Governance Prevents Corporate Risks When the Business Bypasses IT" ). Several different levels of risk assessment rigor should be defined, based on the data or use case criticality or classification (see "Toolkit: SaaS Security Decision Framework" for a life cycle framework mapping data confidentiality requirements to level of effort). This will ensure that strategically important use cases are well-analyzed, without unnecessarily reducing the flexibility to quickly deploy SaaS on a departmental basis.

2. Every SaaS application must have an explicit owner.

If IT is not maintaining responsibility for a particular SaaS application, then the owner is typically a BU manager or department head. For larger enterprises, it may be necessary to track several defined roles:

  • Who pays for each application?
  • Who administers each application?
  • Who takes responsibility for enforcing policy and will accept the risk of failures or incidents?

3. A comprehensive cloud application inventory must be maintained.

The defined approval and responsibility acceptance processes must include a formal registration of SaaS use with IT. If more than a few dozen SaaS services are in use, then it is usually necessary to formally track them in a spreadsheet, database or governance, risk and compliance (GRC) tool. At a minimum, the tracked information should include:

  • Name and type of SaaS service
  • Owner (and other roles if used)
  • Data sensitivity or significance (such as confidentiality, integrity, availability and regulatory compliance)


First thoughts


SPRA process

  • initial risk evaluation
  • questionnaire
  • assessment
  • required actions
  • reevaluation
  • process ownership
  • circumstances
  • approved services, with scope limitations


Identity and access

Operational documentation


Access controls

Mobile devices

Required controls

  • application-level enryption
  • data deletion
  • transfer encryption TLS/VPN/certificates
  • logging
  • notification
  • backup
  • contingency plan


  • No labels