---
sourceDocument: Australia Strategic Portfolio Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/it-business-management

 Release :

    - australia

ft:locale :

    - en-US

ft:publication_title :

    - Australia Strategic Portfolio Management

ft:clusterId :

    - itbm

bundleId :

    - itbm

workflow :

    - Technology


---

# Additional security

# Additional security with Extended Security for EWD {#ariaid-title1}

Release version: Australia  
Updated September 1, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read
Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Additional security with Extended Security for EWD

Additional security is an optional Access Control List (ACL) enforcement feature available with Extended Security for Enterprise-Wide Deployment (EWD) in Strategic Portfolio Management.
It provides enhanced data protection by enforcing partition-based access controls at the database level for four key partitioned tables: Project, Demand, Program, and Portfolio.
This feature ensures that users can only interact with records within their assigned partitions, adding a robust layer of security beyond traditional role-based access control (RBAC).
Show full answer Show less  

## Key Features

* **Partition-based ACL Enforcement:** Users can read, create, update, and delete records only within their assigned partitions for enabled tables.
* **Tables Supported:** Project (pmproject), Demand (dmndemand), Program (pmprogram), and Portfolio (pmportfolio).
* **Independent Table Configuration:** Additional security can be enabled individually for each table via the SPM Configure console.
* **Database-level Enforcement:** Access control is enforced at the database level, independent of roles, ensuring consistent partition isolation.
* **Automatic Partition Assignment on Create:** New records are automatically assigned to the user's partition.

## When to Use Additional Security

* When strict data isolation between partitions (such as business units or geographic regions) is required.
* To meet compliance mandates requiring partition-level access controls (e.g., SOX, GDPR, HIPAA).
* For multi-tenant deployments needing guaranteed data segregation between customers.
* To prevent accidental cross-partition data access that might arise from role-based permissions.

## Access Model

Additional security complements, but does not replace, partition assignments. Users must be assigned to partitions through roles linked to partitions, team membership scoped by partitions, or direct assignment in the user record. Users can access only records within their assigned partitions. Enterprise administrators assigned to multiple partitions can access all records across those partitions.

## Configuration

Enable additional security on a per-table basis in the Strategic Portfolio Management Configure console under Partitions by selecting the checkbox for each table to enforce partition-based ACLs. Changes apply immediately after saving, and existing records retain their partition assignments while access restrictions apply to all future database operations.

This feature allows ServiceNow customers to strengthen data isolation and compliance in Enterprise-Wide Deployment environments by ensuring partition boundaries are strictly enforced at the database level.  
Additional security is an ACL enforcement feature available with Extended Security for Enterprise-Wide Deployment that applies partition-based access control to four partitioned tables: Project, Demand, Program, and Portfolio.

## What is additional security? {#additional-security-with-extended-security-ewd__section_sdt_bm1_lkc}

Additional security is an optional feature that strengthens access control in Enterprise Wide Deployment by enforcing partition-based ACL (Access Control List) rules at the table level. When enabled for a table, users can only read,
create, update, or delete records within their assigned partition, regardless of their role or existing table permissions.

This provides a second layer of protection beyond traditional role-based access control (RBAC), ensuring that partition boundaries are enforced at the database level.

## Supported tables {#additional-security-with-extended-security-ewd__section_tdt_bm1_lkc}

Additional security is available for four tables in Strategic Portfolio Management with Extended Security for EWD.

* Project (pm_project) --- Work initiatives and deliverables
* Demand (dmn_demand) --- Work requests and capacity planning
* Program (pm_program) --- Collections of related projects
* Portfolio (pm_portfolio) --- Strategic collections of programs and projects

{#additional-security-with-extended-security-ewd__ul_udt_bm1_lkc}

You can enable additional security for any combination of these tables. Each table can be configured independently.

## How it works {#additional-security-with-extended-security-ewd__section_vdt_bm1_lkc}

When additional security is enabled for a table, every database operation is subject to partition-based ACL validation:

* **Read:** Users see only records assigned to their partition
* **Create:** New records are automatically assigned to the user's partition
* **Update:** Users can modify only records in their partition
* **Delete:** Users can delete only records in their partition

{#additional-security-with-extended-security-ewd__ul_wdt_bm1_lkc}

ACL enforcement occurs at the database level and is independent of role assignments, ensuring consistent access control regardless of how permissions are configured.

## When to use additional security {#additional-security-with-extended-security-ewd__section_xdt_bm1_lkc}

Enable additional security when:

* Your organization requires strict data isolation between partitions (business units, geographic regions, or separate entities)
* Compliance regulations mandate partition-level access controls (SOX, GDPR, HIPAA, etc.)
* You operate a multi-tenant deployment where customer data must remain segregated
* You want to prevent accidental cross-partition data visibility through role-based permissions
{#additional-security-with-extended-security-ewd__ul_ydt_bm1_lkc}

## Access model {#additional-security-with-extended-security-ewd__section_zdt_bm1_lkc}

Additional security does not replace partition assignments. Users must still be explicitly assigned to partitions through:

* Role assignments linked to partitions
* Team membership with partition scoping
* Direct partition assignment in the user record

{#additional-security-with-extended-security-ewd__ul_a2t_bm1_lkc}

When additional security is enabled, users can only access tables and records within the partitions they are assigned to. Enterprise administrators with access to multiple partitions can see records from all their assigned
partitions.

## Configuration {#additional-security-with-extended-security-ewd__section_b2t_bm1_lkc}

Additional security is configured on a per-table basis in the SPM Configure console under Partitions \> Enable additional security. Each table has a checkbox; when checked,
partition-based ACL enforcement is enabled for that table.

Changes take effect immediately after save. Existing records retain their partition assignment; access restrictions apply to all future queries. For instructions to enable additional security, see [Enable additional security for partitions](https://servicenow-prod.fluidtopics.net/0KKA4giiZgJ07LnMmmqEow "Enable additional ACL enforcement for partitioned tables to strengthen access control validation. Select the tables where you want to apply enhanced security.").

