White paper does not qualify as a third-party security attestation. In other words, white papers are not issued by independent third parties and, more importantly, do not serve as valid attestations. Vendors can make any claims they wish in white papers, without any obligation to ensure transparency or completeness. Generally, white papers function more as marketing materials than as tools for demonstrating compliance.
When renewing an existing technology, including the ticket number from the previous acquisition request can significantly expedite the review process. This is especially important for cloud platforms, which are typically subject to the highest level of scrutiny.
Please do not submit a security attestation with a request unless sensitive data is involved. Doing otherwise sends mixed messages.
Online educational content can often entail sensitive information if students must register or create a profile. Please be careful about this.
Please keep an eye out for reviewer queries. The current architecture of BuyIT™ suspends the review process until a customer has responded to all outstanding queries. The acquisition process cannot advance until outstanding questions have been addressed.
Responding to reviewer questions via email is less than optimal. Because it allows important information to be lost in email inboxes. For the sake of maintaining an audit trail and facilitating oversight, we ask that responses be submitted to BuyIT™ as it is a central repository that is archived and accessible to 3rd parties.
Short-term thinking has long-term consequences. If a vendor cannot satisfy requirements set by the reviewers or Procurement, a Risk Acceptance form should be considered an exceptional practice rather than the norm. The rules are in place for a reason. Automatic risk acceptance will eventually undermine SF State's policies to protect its data.
Most acquisition processing delays result from customers not conducting the necessary due diligence before submitting a request. The Security Team performs its reviews as quickly as the customers allow us to. In light of this, asking the Security Team to expedite a request is tone-deaf.
Please work with your local IT service desk to ensure that you submit your acquisition request using the correct category.
Contacting the Security team directly via email is not a constructive way to expedite the security review. To ensure that critical information doesn't become lost in the shuffle, use BuyIT as the primary communication channel.
Please don't leave us in the dark. If you no longer wish to pursue an acquisition or realize a request is otherwise unnecessary, please ensure you communicate this matter promptly.
All acquisitions that are not explicitly pre-approved will necessitate security and accessibility reviews. Not because we like to hassle people but because of an audit finding from the Chancellor's Office.
Please make sure to collect the necessary documentation before launching the process.
More information is not necessarily better; focus on the kinds and amounts of sensitive data involved.
Be on the lookout for queries. If a query goes unanswered, a ticket will remain on hold (and cannot progress forward) on the BuyIT platform.
If a submission is for a technology that involves Level 1 (or Level 2) data and is a renewal, please specify the Service Now ticket number of the previous submission for reference. Doing so will speed things up substantially.
Out of the Office Status: If you plan to be out of the office, please mention that in the TAR so the reviewer does not interpret a lack of response as disinterest.
Be Prepared for multiple conversations in the TAR: The TAR ticket now folds in the Security and Accessibility review into the same ticket, which can be confusing. Please be aware and ensure you read through the TAR ticket conversations to review and/or respond to the correct activity.
Work with the Service Team: Please don't contact the accessibility and security reviewers about the status of a TAR once they have completed their reviews. They have carefully defined roles that end once they've approved a request. The Service Desk owns and maintains the TAR process.
Know your Approvers: Sending a message to service@sfsu.edu regarding an existing ticket will likely merely append a message to the ticket. If no one is watching the ticket, you are unlikely to get a reply. The Service Desk gets thousands of emails every day.
Check your TAR: Emailing the service desk for an update on a submission will not likely expedite processing. Examining the ticket directly to identify potential bottlenecks is far more constructive.
Know your Approvers: For most tickets, three teams typically must grant approval: the local IT service provider, the security team, and accessibility. These teams all work independently.
Detailed Case Description: A detailed use case description, which describes what a technology does and how a campus function unit plans to leverage it, is necessary to perform a security assessment. Internet URLs are not a viable substitute for a use case description and performing the necessary due diligence. Especially when Level 1 and Level 2 data are involved.
Status Updates: It's easy for emails to get lost in the shuffle. If you're wondering why the approval process is taking so long you might want to directly sign in to Service Now and inspect your submission. There may be outstanding questions that have not been addressed.
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.