Resources

1. Overview

The Resources section is the central reference library of Siberson Verikor DLP. Every detection rule, classification policy, and enforcement action defined elsewhere in the platform draws on building blocks that live here — the keywords a dictionary matches, the categories a policy belongs to, the severity assigned to a violation, the enforcement action taken at an endpoint, and the metadata propagated to third-party classification engines.

This article walks through every page under the Resources menu, in the exact order the navigation presents them, and explains what each page controls, what the edit form exposes, and how administrators should maintain it over time.

2. Accessing the Resources Section

All Resources pages are available under the Resources menu in the left-hand navigation of the Verikor DLP Administration Console. The navigation presents fourteen sub-sections in a deliberate order — from detection inputs (Dictionaries, Policy Categories, Regions, Industries, Rule Categories) through technical boundaries (Domains, Networks, User Directories), to manually-defined objects (Custom Users, Custom Computers, Custom Actions, Other Devices), and finally operational and integration resources (Severities, Meta Data Labels).

1. Sign in to the Verikor DLP Administration Console.

2. Expand Resources in the left-hand navigation panel.

3. Select the sub-section you wish to manage — each opens a list view with New, Details, Edit, Delete, Display Columns, and Export to Excel controls.

3. Dictionaries

Dictionaries are curated keyword lists that Verikor DLP matches against content at rest, in use, and in motion. Each dictionary has a name, a description, an Active flag, and a list of keywords. Dictionaries are referenced from detection rules — either on their own, or combined with regex and other conditions to narrow the detection scope.

Figure 1 — Dictionaries list view (Resources › Dictionaries)

‌

The list view displays every dictionary currently in the system, its description, and whether it is active. Out-of-the-box Verikor ships with dictionaries for international sensitive-data scenarios — system file types, VALID/CVV keyword lists, password descriptors, sexual and religious preference markers, blood types, system admin identifiers, corporate and financial terminology, and role-specific lists such as KariyerNet CV indicators.

3.1 Creating and Editing a Dictionary

Clicking New or the pencil icon on an existing row opens the Dictionary edit form. The form exposes a name, an active toggle, a description, and the list of keywords that make up the dictionary.

Figure 2 — Dictionary edit view showing metadata and keywords

‌

4. Policy Categories

Policy Categories group policies by regulatory or business purpose. They do not enforce anything on their own — instead, they classify policies so that dashboards, reports, and exports can be filtered by category, and so that audit teams can answer questions like “show me everything related to GDPR” or “list all Attorney-Client Privileged Content controls.”

Figure 3 — Policy Categories list view

‌

Verikor ships with a broad catalogue of 100+ categories covering regulatory frameworks (KVKK, GDPR, HIPAA, PCI-DSS, APPI, AML, the EU AI Act), protection scopes (AI Model & Prompt Protection, AI Training Data Protection, Biometric Data Protection, Banking & Financial Services, Authentication Credential Protection), and specialised content types (Attorney-Client Privileged Content, Aviation & Travel Data, Audit Trails and Security Logs).

4.1 When to Create a New Category

• When your organisation introduces a new regulatory obligation not already covered by the shipped categories (for example, a sector-specific circular from BDDK or SPK).

• When an internal policy domain — such as an M&A data room, a research group, or a specific customer contract — warrants its own grouping for reporting purposes.

• When you want to separate “detect only” and “enforce” policies into clearly distinct categories for operational dashboards.

5. Regions

Regions associate policies, users, and endpoints with geographic or regulatory territories. They are used both for scoping — applying a policy only to assets in a specific country or economic zone — and for reporting, so that incident response teams can triage events by jurisdiction.

Figure 4 — Regions list view

‌

The shipped region catalogue covers continents (Africa, Asia, Europe, AMER), blocs (APAC, ASEAN, BRICS, CIS, Eastern Europe), individual jurisdictions with specific privacy regimes (Brazil under LGPD, Canada under PIPEDA, Australia under the Privacy Act 1988, China under PIPL/DSL), and a universal Any region for policies that apply everywhere.

5.1 Typical Uses

• Applying stricter controls to data processed in regions with active privacy regulators (for example, restricting cross-border transfer of personal data tagged as originating in the EU or Turkey).

• Scoping data-residency rules — for example, preventing upload of EU-origin content to storage services not listed under an approved EU region.

• Building regional executive dashboards that summarise incidents by territory rather than by business unit.

6. Industries

Industries tag assets and policies with a vertical context. This is useful in two scenarios: large organisations operating across multiple regulated verticals, and managed security service providers (MSSPs) running Verikor DLP on behalf of different customers.

Figure 5 — Industries list view

‌

The shipped list includes 25 verticals — Aerospace, Agriculture and AgriTech, Automotive, Chemical and Pharmaceutical, Defense Industry, Education, Energy, Finance, Food and Beverage, Government, Healthcare and Medical, Information Technology (IT), Insurance, Legal and Consulting, and more. A universal ALL entry exists for policies that are vertical-agnostic.

7. Rule Categories

Rule Categories classify detection rules by the type of content they match. Unlike Policy Categories (which describe why a policy exists), Rule Categories describe what a rule detects — Card Security Codes, Bank Account Numbers, Biometric Identifiers, Authentication Tokens, and so on. This distinction matters because one rule category can appear in many different policies.

Figure 6 — Rule Categories list view

‌

The shipped list of 80+ rule categories covers everything from payment-card artefacts (Card Expiration Dates, Card Security Codes, Card Track Data) to AI/LLM concerns (AI / LLM Service Credentials, AI-Generated Content Markers), anomaly patterns, API credentials for third-party services, authentication tokens, biometric identifiers, birth and death certificate numbers (including Turkish nüfus kayıt formats), and classification markings (TOP SECRET, NATO RESTRICTED, ÇOK GİZLİ).

7.1 How Rule Categories Relate to Rules

Each individual rule defined under Policies is assigned to exactly one Rule Category. The category description typically includes concrete examples of what the rule should match — for instance, the API Keys — Third-Party Services category lists Stripe, PayPal, GitHub, Slack, Twilio, and SendGrid as expected patterns. When creating new rules, align them with an existing category wherever possible; only create a new category when none of the existing ones describes the pattern cleanly.

8. Domains

The Domains page registers the Active Directory / Entra ID domains from which Verikor DLP enumerates users and computers. Every user synchronised from a directory, and every endpoint that reports telemetry to the console, is associated with one of the domains defined here.

Figure 7 — Domains list view

‌

8.1 Typical Configurations

• Single-domain deployment — one entry covering the entire organisation.

• Multi-domain deployment — one entry per trusted child domain, plus any acquired-company domains during an M&A integration window.

• Partner collaboration — a separate entry for each external partner domain whose users routinely exchange content with the organisation and need to be evaluated in policies.

9. Networks

The Networks page defines named IP ranges — trusted corporate networks, VPN subnets, DMZ ranges, partner subnets, and any ranges that should be explicitly excluded. Networks are then referenced in policies to drive different behaviour on-net versus off-net (for example: audit on-net, block off-net for the same sensitive-data movement).

Figure 8 — Networks list and edit form (Start / End IP range)

‌

The edit form captures a Name, an optional Description, an Active flag, and a Value section where the IP range is defined by Start and End addresses. Multiple ranges can be added to a single network entry by adding additional rows to the Value table — useful for networks that span non-contiguous subnets.

10. User Directories

User Directories configures the connections to identity providers — Active Directory, Entra ID, LDAP, or local directory services — from which Verikor synchronises users and groups. A single environment typically has one primary directory plus any secondary sources used for guest, contractor, or service-account populations.

Figure 9 — User Directories list and edit form (LDAP query)

‌

Each directory entry captures a Name, an Active flag, a standard LDAP Query string that determines which directory objects are imported, and an optional Description. The default shipped query — (&(objectClass=person)(objectClass=user)) — imports all user accounts while filtering out groups, contacts, and computer objects.

11. Custom Users

Custom Users are manually-defined identities for principals that fall outside the directory-synchronised model — external contractors, auditors, temporary collaborators, and service accounts that should not appear in the primary directory but still need to be referenced in policies.

Figure 10 — Custom Users list view

‌

The list view exposes columns for Domain, Username, First Name, Last Name, and E-Mail. Each custom user is effectively a stand-in for a real person or account that needs policy coverage but cannot be imported through the standard directory connector.

11.1 Typical Use Cases

• External auditors granted temporary access during a compliance review — created as custom users so their activity is logged under their real identity rather than a shared audit account.

• Contractors working under time-boxed engagements who use corporate endpoints but whose accounts live in an external directory not federated with Verikor.

• Service accounts and automation principals that should be explicitly excluded from interactive-user policies (for example, backup agents, deployment bots).

12. Custom Computers

Custom Computers are manually-defined endpoint records for machines that carry a Verikor agent but are not discovered through directory synchronisation — typically bastion hosts, kiosks, lab machines, and unmanaged devices.

Figure 11 — Custom Computers list view

‌

The list view exposes columns for Name, OS Architecture, Operation System, and OS Service Pack. Each custom computer is referenced in policies in exactly the same way as directory-discovered computers, so policies scoped to “all Windows endpoints” automatically include matching custom computers.

12.1 When to Use Custom Computers

• Lab or research endpoints that are intentionally not domain-joined but still need DLP coverage.

• Kiosks, terminals, and single-purpose machines that operate outside the standard provisioning pipeline.

• Bastion hosts and jump boxes used for privileged access — where DLP visibility is critical even though the host is not a normal user workstation.

13. Custom Actions

Custom Actions define what happens when a policy rule triggers. This is one of the most operationally important Resources pages — getting the action catalogue right determines how aggressive, how verbose, and how user-visible your DLP enforcement becomes.

Figure 12 — Custom Actions list view

‌

Verikor ships with a tiered action catalogue that covers the full spectrum from silent observation to channel-specific blocking:

13.1 Configuring an Action per Endpoint Channel

Opening a Custom Action reveals a per-channel configuration panel. Each action specifies what should happen across each endpoint channel independently — external USB devices, removable media (CD/DVD), email, printers, hard drives, and virtual devices — plus a Default fallback for channels not listed. This per-channel granularity is what distinguishes Verikor enforcement from a simple allow/block model.

Figure 13 — Custom Action edit view showing per-channel behaviour

‌

14. Other Devices

Other Devices covers non-computer assets monitored by Verikor — network printers, multi-function devices, scanners, and any peripherals that need to be identified at the device level rather than through a host agent. Registering these devices allows policies to apply controls based on the device itself rather than on the user or host interacting with it.

Figure 14 — Other Devices list view

‌

15. Severities

Severities assign a numeric weight to every detection event. They drive incident prioritisation, SOC workflows, and SLA calculations. Verikor ships with a four-tier severity model that aligns with most security incident-management frameworks.

‌

Figure 15 — Severities list view

‌

Most organisations keep the shipped four levels unchanged — they map cleanly to typical SOC tiering and to the way dashboards visualise incidents. If a custom tier is required (for example, a Very Low level for informational events), add it with the next unused numeric value and update any dependent rule and dashboard references.

16. Meta Data Labels

Metadata Tags act as a bridge between Verikor DLP and external classification ecosystems, including its accompanying Siberson Veriket Data Classification product and other classification products. Each tag associates a human-readable name with structured Key/Value data that subsystems can consume.

Figure 16 — Meta Data Labels list view

‌

The list view shows the label name, the Key it writes into (for example, SensitivityPropertyName for MIP integration, or VeriketClassification for Veriket integration), and a preview of the Value that will be applied.

16.1 The Meta Data Label Edit Form

‌

Figure 17 — Meta Data Label edit form

‌

17. Maintenance and Governance

The Resources catalogue grows over the lifetime of a DLP deployment. Without discipline, it becomes difficult to understand which dictionaries, categories, and actions are actually in use. A few simple habits keep the catalogue healthy:

• Review dictionaries quarterly. Deactivate any that are no longer referenced by a live rule. Verikor keeps them in history but removes them from the active evaluation path.

• Export the Resources lists to Excel before any major rule-set change. This gives a simple rollback reference point if a change needs to be reversed.

• Document the intent of every new Rule Category and Custom Action in its description field — not in external runbooks. The description travels with the object across environments; a runbook does not.

• Avoid deleting resources that have historical references. Deactivate instead. Deletion breaks historical incident reports that reference the resource by ID.

• When promoting from test to production, migrate Resources first (Dictionaries, Rule Categories, Meta Data Labels, Custom Actions) before migrating the Policies that depend on them.

18. Summary

The Resources section is where the vocabulary of your DLP deployment is defined. Dictionaries describe what to look for; Policy Categories, Rule Categories, Regions, and Industries organise and scope those detections; Domains, Networks, and User Directories define the technical boundaries; Custom Users, Custom Computers, and Other Devices cover objects outside the standard directory model; Custom Actions determine what happens when a rule triggers; Severities determine how loudly the event is escalated; and Meta Data Labels propagate classification decisions outward to Microsoft Information Protection and Siberson Veriket.

Every later article in this knowledge base — Policies, Classifications, Reporting — assumes a correctly-configured Resources catalogue. Time spent here is recovered many times over in rule authoring, audit readiness, and operational clarity.

‌

Last updated: 2026-04-23