Be explicit with the information provided on the TAR: Security Analysts are not domain experts in the technology that is being acquired. Using acronyms and cryptic references to specific use cases will lead to additional questions and increase the amount of time required to process a TAR.
Be prepared to provide all the information: Departments that process Level 1 and Level 2 data (e.g., confidential) as part of their normal operation should ensure supporting documents are available for the TAR submission. Waiting for the Security Analyst to request security attestation documents will delay the TAR processing. TAR tickets for large projects involving substantial amounts of sensitive data can be processed in less than a day when they include attestations and a detailed use case description.
TAR is Essential: Escalating a concern to circumvent a TAR is not advised. Security and accessibility review are processes mandated and enforced by the Chancellor's Office.
Renewals: In the event of a renewal, including the ServiceNow ticket number from the previous TAR can speed up the process substantially.
Vendor Interaction: It is the responsibility of the campus unit that has submitted a TAR to coordinate with the vendor to answer any relevant questions that may emerge during the review process.
Existing Vendors: If a vendor already has a contract with the CSU or SF State, please have Procurement vouch for the agreement's validity and provide related documentation.
Tip #1 - It is the responsibility of the campus unit that has submitted a TAR to coordinate with their vendor to answer any relevant questions that may emerge during the review process.
Tip #2 - If a vendor has an existing contract with the CSU or SF State, please have Procurement vouch for the agreement's validity and provide related documentation to this end.
Attachments Are Not Replacements for Descriptions: Attaching a sales brochure to a submission is not a viable substitute for a worded description indicating what a technology does and how SF State plans to use it. Please take the time and energy to write up a legible use case.
Do Not Attach Outlook Messages: Please do not attach Outlook messages to a ticket. Instead, copy the raw text of the message to the ticket directly so you can read it from within Service Now.
Provide Previous Ticket # When Renewing: In the case of a renewal, having access to previous ServiceNow ticket numbers and documentation will substantially speed up processing time. This means when a particularly large purchase is approved, it's a good idea to track all the associated information for future reference.
Look for Follow-Up In Your Inbox: Be sure and mind your inbox. If the analyst processing a TAR has not received a response to their questions (particularly if they pose their questions repeatedly) they will eventually conclude that you are no longer interested in pursuing an acquisition.
Do Not Bundle
In general, we do not advise "bundling" items based on past experiences with this practice. Obviously, we're aware that it's easier to submit one TAR instead of many, but history has shown that the downside in terms of complexity, tracking, and potential confusion override the benefits.
TARs Are Required as Part of an Audit Finding
It is not a good idea to try and "escalate" a TAR to avoid having to conduct security and accessibility reviews. These processes are mandated and enforced by the Chancellor's Office.
Do not submit piecemeal
Please do not submit documentation and use-case information piecemeal, as things tend to get lost in email inboxes. Please submit everything all at once when the actual TAR ticket is instantiated.
Delegate with proper information
If the technology's owner is going to delegate the process of submission, they are responsible for conveying all the necessary information and documentation to their delegate so that the delegate does not merely become an intermediary.
Do not assume
Do not assume that the security review person is familiar with the technology stack in question. Please clarify all acronyms and proactively supply background context to save time.
Do not submit just a diagram
Diagrams help, but they are not sufficient. Please supplement diagrams with a written summary that spells out the details suggested above.
Know the Product
The requestor submitting a TAR request should be the most knowledgeable person regarding the technology in question to facilitate direct communication and avoid having to engage multiple 3rd parties
There is no guarantee a submission for renewal will be approved.
Be prepared to provide documentation and background material if the previous security review ticket number cannot be located. You will want to refer to the first tip.
Our security analysts are responsible for ensuring a properly documented procedure is in place when assisting with TARs. If they ask for more information, remember that it is their goal to ensure that all data pertaining to our staff, faculty, and students are kept safe. So, while it might seem frustrating, the process is designed with our customers' safety in mind.
The TAR process can be one that is rather involved, especially for technology that interacts with sensitive data. Focus on providing as much useful information as possible to ensure the TAR is easier. While this may seem frustrating, the clearer the information, the quicker the overall process.
When submitting a TAR, please provide specific details about how the technology requested will be implemented on campus. What sort of hardware and software will be involved? Will data flows to or from other endpoints/platforms on campus or in the cloud be used? Will this involve any SF State data elements?
If you are unsure about any of these questions, please get in touch with us. Provide these answers to avoid any delay to your request. Let us know if you are looking into an issue and need more time. Otherwise, we will assume that unresponsive submitters are no longer interested in pursuing an acquisition.
If there is any doubt about whether a TAR is necessary or not, please submit a TAR.
For questions regarding TARs, please do not contact individual analysts who may be out of the office. Please contact the security team at security@sfsu.edu.
Keep your eyes on your inbox. After the request for a TAR security review has been assigned, the ITS Security Team usually responds within 24 hours with approval or questions.
- Most subsequent delays are the result of customers not responding to our questions.
Maintain Open Channels of Communication
- Even if you don't have the answers to all our questions, kindly let us know that you're investigating and provide a timeline for getting back to us. In other words, please let the ITS Security team know if there will be any delays in communication when submitting a TAR.
Before making a TAR submission that involves sensitive SF State data (e.g. Level 1 or Level 2) in a cloud service, please acquire the necessary documentation around such a request before launching the TAR process.
- A list of cloud computing acquisition documents can be found here: https://its.sfsu.edu/content/documentationtechnologyacquisitionreview
Don’t submit a TAR if you’re going to be out of the office following the submission.
- Open and responsive communication channels go a long way toward expedient processing.
Ensure the best person to answer the required questions submits the TAR.
- It would be helpful if the person with the deepest understanding of technology conducts the submission. This will minimize impact and help to move the TAR through faster.
Providing Incomplete Information/Description of the Technology Requested
- Please ensure all information regarding the requested technology is provided so that subsequent data requests are not required. This will minimize impact and help to move the TAR through faster.