Some data may be restricted due to sensitivity, hence only a subset of users should be able to access.

SSO is an authentication scheme that allows a user to log in with a single ID, which means once you have logged on to your computer, the application should be able undertake authorisation based on the credentials used to log into the computer without the user having to re-enter then, or enter credentials specific to the application. This enhances the security of the system. For example, when a user leaves an organisational, access to the application is automatically removed when their organisational login is disabled.

Any security claims by the vendor should be backed up with official documentation, not just their say so or statements in emails. Having official security documentation allows any organisation staff to use the documentation as reference to answer any questions which may not have been covered. For example security specialist will have a set of criteria which the system needs to pass before it can be used for a pilot let alone production. These documents removes the need to have meetings to clarify specific questions. Any vendor which uses AWS, Azure or other reputable cloud service provider for their data storage and application service should immediately be able to provide links to these cloud services security documents. Documentation ideally would include information such data storage and fail over locations, and frequency of penetration tests, as well as a many other security details.

THIS IS EXTREMELY IMPORTANT TO UNDERSTAND! Any system which stores the username and password, or credentials of another system is a MAJOR SECURITY RISK! If it does, undertake an extensive security assessment to determine where and how this information is stored and encrypted. For example if a GIS web application can consume data from another application, for example TeamBinder and that application asks for your username and password to synchronies the data then this is a major security risk. No system should store or ask for a users credentials directly to access data or processes from another system. There are a number of ways data from 3rd party systems can be accessed. One of the most common methods is using a token which is associated with the application to authorise access and has an expiration date. This means the token can only be used by the application and does not work after a certain date. A secure way a token can be generated is the application url is registered with the 3rd party system it wants to access. When the application tries to access this data it checks if a token is sent and valid. If a token is not present, the it will check to see if the url of the application is registered and allowed. If it is, the 3rd party system will undertake its authentication process to authenticate the user. When successful a token will be generated and passed back to the requesting application via a callback url. This callback will initiate a process to store the token and subsequent calls to the 3rd party system will pass the token to authorise access.

With the release of Google Maps, Google Maps Global Mercator has become a popular default map projection to use and is supported by many mapping applications. This projection is now more commonly known as WGS 84 / Pseudo-Mercator, and is a projection to consider when representing data at a "Global" scale. Most specialist Geospatial applications in my opinion are at a local, region, state or country scale, and as such should use the appropriate scale. EG. Melbourne: GDA2020 / MGA zone 55, Victoria: GDA2020 / Vicgrid, Australia: GDA2020 Would expect to use map projection relative to the area. Usually data is collected in the relevant map projection or re-projected to that projection from GPS collected data. If the data is re-projected to be displayed in in the application other than the projection used for data collection, then errors in the data will be introduced. This is especially important to consider when dealing with critical infrastructure data such as utilities and should be noted in the Metadata.

Metadata is the key to understanding the quality, relevance, and currency of the data you are viewing. Without it how can you be sure it is any good? Every Geospatial application and process must be able to produce and consume metadata. Anything other than that indicates it is not worthy to use.
Metadata standards have been around since the 1980s. The current standard AS/NZS ISO 19115.1:2015 Geographic information - Metadata was first released in 2003

When pilot program has been agreed, vendors will usually create a project of the area of interest using freely available data. Ensuring reliable data is used for the features such as base maps during the pilot will ensure continual use during production. Depending of location, one would expect the Authoritative Data provider for the region to be used for base data such a roads, address, property.

You have something solid to refer to later on. It also builds trust with the vendor that what they are saying is true. Would expect to be provided as documentation (PDF) or links to their website or sites of utilised infrastructure.