REFERENCE ARCHITECTURE GUIDE FOR ZIA
22©2022 Zscaler, Inc. All rights reserved.
Set up AUP acceptance and end-user notifications
To get started, collect the policy and messaging that you developed earlier in this guide. At this stage, you should have the
following notification and messaging approved and ready for configuration:
● An approved Acceptable Use Policy (AUP) – This is the document users agree to when they connect for the first
time, and as oen as required by your legal team. You should configure this policy before you begin testing, ensuring
all users have accepted the AUP. You can learn more information about AUP configuration and acceptance at
Configuring the Acceptable Use Policy (hps://help.zscaler.com/zia/configuring-acceptable-use-policy).
● Documented website for AUP and escalations – It is inevitable that your users will aempt to access a resource
that is blocked by inspection. These blocked aempts trier an escalation by the user if they feel that the resource
is legitimate. It is a best practice to document your escalation procedures on your organization’s intranet page.
Your procedure should include your AUP, and what block and caution notifications mean. It should also include
the procedure by which a user can have the destination reviewed by your IT and policy staff to ensure correct
categorization. Link to this procedure document in your Block and Caution notification.
● Block notification – This message is displayed when the system blocks access to a resource, either because of a policy
that you have set, or because of a bad certificate presented to the ZIA Service Edge. This notification can include a
default message, or you can customize the message to include specific text. Zscaler recommends linking to your AUP
and escalations site. Finally, your message can contain limited HTML styling to allow you more customization options.
You can learn more about configuring a block notification at Configuring Block Notifications (hps://help.zscaler.
com/zia/configuring-block-notifications).
● Caution notification – Much like the block notification, the caution notification is triered by user action. The
action can be an aempt to reach a site that has questionable value to the organization. An example of problematic
websites can include streaming media sites with user-generated content, or just a viral video. In this case, the
caution notification is appropriate, and the user can make the choice to proceed or abandon their browsing. Zscaler
recommends linking to your AUP on caution notifications, providing more detail on the policy You can learn more
about configuring caution notifications at Configuring the Caution Notification (hps://help.zscaler.com/zia/
configuring-caution-notification).
● Initial policy controls roadmap – It’s likely that your organization already has classes of sites, web applications, or
special deployments that you want to gain control over. These can include things you wish to outrightly ban, such
as gambling or adult content. It can be things you’d like more control over, such as who can access social media and
when. These policy decisions will be implemented in the next steps.
When you have these notification and messaging items in place and configured, you are ready to develop your policy
and begin applying it to users. In the next section, you will focus on your pilot users, who will be the first to go through
inspection as you work out your initial policy. You use the pilot group to test and become comfortable with the policy
before you roll it out to your entire organization.
Selecting your pilot group
The first users you onboard, the pilot group, need to understand that they may experience some issues and disruption.
Select a group of users that can handle the interruption. You don’t want to include users that are at a critical time of year
in either their product development or regulatory calendars. While changes to policy can be rapidly rolled back, you want
to avoid that scenario. Select a minimally vulnerable group and ensure that you have that group’s full cooperation before
starting the pilot program.
The pilot team ideally will not be your IT or development staff, because IT and development users oen try to work
around issues before reporting them. Additionally, their work oen entails operating in an environment that does not
match that of the average user. See Developer environments for more information on deploying development teams.