# How to Block Employees from Accessing Websites Containing Sensitive Information

Canonical: https://www.nsecsoft.com/en/course/web-control-keywords.html

Language: en-US

Updated: 2026-11-04T08:00:12.116776Z

In the scenario of website browsing, the risk faced by the enterprise is not only "visiting websites that should not be visited", but also including employees retrieving, browsing or accessing content containing sensitive information on the web\. Through Ping32's sensitive word blocking, administrators can identify and intercept web page access behaviors that contain specific sensitive \[…\]

In the scenario of website browsing, the risk faced by the enterprise is not only "visiting websites that should not be visited", but also including employees retrieving, browsing or accessing content containing sensitive information on the web. Through Ping32's

**sensitive word blocking**

, administrators can identify and intercept web page access behaviors that contain specific sensitive content based on keywords or regular expressions, thereby blocking risks in advance during the browsing process.

This capability is suitable for content that needs to be protected, such as confidential words, project code names, customer privacy, financial keywords, core business terms, etc. If the enterprise already has a relatively mature sensitive word management system, it will be more efficient and stable to store common rules in the sensitive word library and then call them in the policy than to enter them manually every time.

#### **First clarify the control idea: whether it is a temporary rule or a long-term rule**

Before implementation, it is recommended to distinguish between two common usages:

-   If you only want to temporarily control a certain special governance cycle, a certain batch of specific endpoints, or a certain type of staged sensitive words, you can directly add new rules in **Sensitive Word Interception**.
-   If these sensitive words will be reused for a long time, or need to be shared by other strategies and other modules, it is recommended to maintain the **Sensitive Vocabulary** first and then reference it in the strategy.

The advantage of this is that the strategy is responsible for "when it takes effect and for whom" and the sensitive vocabulary is responsible for "what content is identified". The responsibilities are clearer and more conducive to subsequent iterations.

#### **Enable "sensitive word interception" through policy**

1\. Click

**Internet Behavior**

→

**Policy**

in the Ping32 Management Console to enter the Internet Behavior Policy Settings interface.

2\. In the Internet Behavior Policy Settings interface, click

**Browse Websites**

and turn on

**Sensitive Word Blocking**

.

3\. Click

**Parameter Settings**

to enter the sensitive word interception configuration interface.

![](<https://www.nsecsoft.com/site-assets/bd479a7e2f6829c160217f5ef8075eb7317c364c4447adfeb14f5da8239c94ec/66bfef5c113efc06b19073ab7a00732e1d27ae57e74077625b31d7919681582e/e38548e51af46d10e875ddd673559bb707381ff4e8c82c021f0a5aa3f5bc933a/2-web-control-keywords-1.png>)

4\. Click

**Add**

on the sensitive word interception interface to configure sensitive word rules:

-   Select sensitivity type
-   Fill in the sensitive name
-   Supports keywords or regular expressions
-   If you need to add multiple keywords at the same time, you can use `;` to separate them
-   Fill in the characteristics
-   Select sensitivity level
-   Choose whether to synchronize sensitive content to the system sensitive vocabulary

It is recommended that administrators focus on two things:

-   The **keyword or regular expression** is chosen to match the recognition target. Fixed vocabulary, department terms, and project names are usually suitable for keywords; content with a more stable format and more changes is more suitable for regular expressions.
-   The granularity of the rules should not be too coarse. Keywords that are too broad can easily lead to false interceptions, especially when browsing websites. It is recommended to give priority to word combinations with obvious business orientation.

5\. After the policy setting is completed, confirm the policy application endpoint.

It is recommended to first enable high-risk positions, pilot endpoints or specific departments on a small scale. Because

**sensitive word blocking**

directly affects employees’ web access experience, verifying the accuracy of the hit first and then expanding the scope can effectively reduce the communication cost caused by misjudgment.

6\. After confirming the policy application endpoint, click

**Apply**

to prohibit employees from accessing websites containing sensitive information.

Additional instructions:

-   In the sensitive word interception interface, you can also directly select sensitive words in the sensitive word library to quickly add them.

If the enterprise already has a sensitive vocabulary database that is maintained uniformly, it is recommended to use this method first. This can ensure that different endpoints and different policies use the same set of identification standards, reducing the problem of inconsistent rule calibers.

#### **Add sensitive words to the sensitive vocabulary database**

1\. Click

**Start**

→

**Library & Templates**

in the Ping32 Management Console to enter the library & template setting interface.

2\. Click

**Sensitive Words**

to enter the sensitive word database interface.

![](<https://www.nsecsoft.com/site-assets/bd479a7e2f6829c160217f5ef8075eb7317c364c4447adfeb14f5da8239c94ec/656df4851b283c9e42e351383a42a8a33263084b4d8bd8dfb9e33a6f3d0b71c3/cbbf939fa34162c02be41062b890c1f7f9d66e61a86e6569105ccd11482c2990/2-web-control-keywords-2.png>)

3\. Click

**Add**

to define sensitive words:

-   Select sensitivity type
-   Fill in the sensitive name
-   Supports keywords or regular expressions
-   If you need to add multiple keywords at the same time, you can use `;` to separate them
-   Fill in the characteristics
-   Select sensitivity level

4\. After saving, you can add sensitive words to the sensitive vocabulary library.

It is recommended to make classification and naming conventions when maintaining sensitive lexicon, such as "financial category, customer category, R&D category, system category, project category", etc. This will make it easier to filter and reuse when later called in different strategies.

#### **Effectiveness verification and rule optimization suggestions**

After the policy is issued, it is recommended to do a minimum verification:

-   Select the test endpoint that has been included in the policy scope.
-   Access the test web page or test content that contains configured sensitive words.
-   Observe whether the access has been blocked.
-   Then visit a normal page that does not contain sensitive words to confirm whether it can be browsed normally.

If you need to further optimize the effect, you can refer to the following ideas:

-   If normal websites are frequently blocked, prioritize checking whether sensitive words are too common, whether rules are too broad, and whether regular expressions lack constraints.
-   If the page that should be blocked is not identified, give priority to checking whether the sensitive words are accurate, whether they are synonymous variations, whether multiple keyword combinations need to be added, or whether regular expressions should be used instead.
-   If a certain type of sensitive words will be used for a long time, it is not recommended to temporarily add them to the policy every time. It is best to maintain them in a unified database of sensitive words to facilitate version management and multi-person collaboration.

From a governance perspective,

**sensitive word blocking**

is more suitable as a front-line defense for high-risk content. First sort out the identification rules, and then deliver them to the appropriate endpoint range in stages through Ping32. This can usually significantly improve the content security control capabilities in web access scenarios without significantly affecting the business.
