Information for Administration / Operations Functions

When examining solutions for a particular problem or initiative, it is important that due diligence be followed.  Due diligence is related to identifying potential risks associated with your initiative and the proposed technical solution you are putting forward, but it could also relate to an environmental scan to ensure that such a solution does not already exist within the institution.

Administration and Operations have particular needs that enable centralized, distributed, support-oriented, research-supporting, and departmental functions to run optimally. Due to the commonality of data involved within many of these areas, it is likely that technical solutions may require technologies to "talk" with each other, or to have corporate data (HE, HR, FIN) provided to or from them. 

Or, these functions may require unique tooling with the capability to conduct very specific, non-corporate data-related processes.  The solution may produce new data that may require an appreciation of their character in detail.

The TRA process is very much concerned with teasing out these risk points and to better allow our administrative and operational departments to make good decisions when it comes to provisioning solutions.

Due to the potential sensitivity of data within our environment, the TRA process brings together the expertise necessary to help you gather the relevant information to make the decisions for your unit.  

Solutions identified through the TRA process as MEDIUM RISK should at least produce a conversation amongst the submission team in terms of accepting and mitigating the risks prior to implementation. Awareness at the AVP level is required for solutions assessed at this risk profile. 

For solutions assessed at a HIGH RISK level, awareness and risk acceptance at the VP level is required.

Finally, as stated in other locations of this website, the TRA report is provided by a collection of experts in areas related to Infomation Technology, Legal, Privacy, Procurement, Financial Services, Internal Audit, and administrators of our corporate data systems.  The committee will render an opinion of the solution and its underlying technologies.  In many cases, given the corporate relationship produced between the institution and a vendor, parallel processes may continue after the TRA report has been delivered.  Specifically, Legal Counsel (for contract negotiations), the Privacy Office (for legislative and regulatory items related to personally identifiable information), and Financial Services (representing the Bankcard Committee where ecommerce activities are required to be PCI-compliant).

A few notes about solutions introduced via the TRA process for administrative and operational needs:

  • Custom-built applications (using in-house or contracted developers) cannot be code-reviewed by the TRA process as this activity is out of scope. The TRA Committee (TRAC) may provide some recommendations to the initator in terms of what may need to be taken into consideration and some follow up may be required by some of the membership.
  • The TRA process is a moment in time exercise. Contract language can change over time, functionality can be added, vendors are acquired by other providers, etc.  Should something material emerge (end of contract, replacement solution, etc.) there will likely be a requirement to revisit the TRA submission.
  • As current applications migrate from on-premise solutions to cloud-based platforms, a TRA submission will be required to understand the risks associated with such a change.  On-premise and cloud-related concerns are quite different from each other and require differentiated approaches in terms of platform and implementation.
  • eCommerce solutions need to be vetted by the Western Bankcard Committee for compliancy reasons (this includes adding modules of an already-approved platform).

 


Published on  and maintained in Cascade CMS.