Skip to content
Notifications
Clear all

Help: Can't figure out how to delegate control ownership temporarily

3 Posts
3 Users
0 Reactions
0 Views
(@davek)
Trusted Member
Joined: 1 week ago
Posts: 55
Topic starter   [#21836]

I'm facing a recurring operational hurdle with Hyperproof that my team's SRE and FinOps workflows are currently butting up against, and I'm hoping the community has encountered and solved this. The core issue is the temporary delegation of control ownership for purposes like covering extended leave (e.g., parental, medical) or during a structured ownership transition period.

Our use case is specific: we need to reassign a set of controls from a primary owner (who will be out for 3 months) to a secondary owner, with the explicit intent of reverting ownership back to the primary after that period. The goal is to maintain clear audit trails and ensure notifications, review tasks, and evidence requests flow to the correct interim person without permanently altering the control's metadata or historical record.

I've exhaustively explored the UI and the available API documentation. The standard ownership change is a permanent, overwriting operation. My attempts so far have been:

* **Manual Reassignment & Calendar Reminder:** This is error-prone and breaks the audit trail. The control's "Last Modified By" and history will show the secondary owner, obscuring the original primary owner's ongoing responsibility.
* **Using Workflow Tasks:** We tried creating a review task for the secondary owner for each control. However, this doesn't make them the "Owner" in the system's eyes. They cannot, for instance, upload evidence on behalf of the control or be the direct recipient of automated compliance alerts tied to the owner field.
* **API Scripting (Pseudo-Code):** I drafted a script to capture and swap owners, planning to run it again to revert.
```python
# Pseudo-code for concept
original_state = {}
for control in controls_list:
original_state[control.id] = get_owner(control.id)
update_owner_via_api(control.id, interim_owner_id)

# ... after 3 months, script to revert ...
for control_id, original_owner in original_state.items():
update_owner_via_api(control_id, original_owner)
```
The glaring issue here is that this still performs two permanent, audited ownership changes. The interim owner becomes part of the permanent ownership history, which from a compliance perspective in certain frameworks (like SOX) could be seen as a misleading record of responsibility.

This feels like a fundamental gap for enterprises practicing mature role-based access control and separation of duties. Has anyone engineered a workaround that satisfies both operational need and compliance rigor?

Potential avenues I'm considering but lack data on:
1. Is there a native "Delegation" or "Temporary Assignment" feature flag in newer versions or enterprise tiers that we've missed?
2. Could a custom role with near-owner permissions, assigned temporarily to the user, combined with a filter/view for "Controls I am delegated to," be a viable path? This would leave the official owner field intact.
3. Are there webhook-driven automation patterns (e.g., using Zapier or a internal service) that can intercept and re-route notifications based on a separate delegation schedule, effectively creating a shadow delegation system?

Any detailed experiences, including API call patterns or permission configurations, would be immensely valuable.


CPU cycles matter


   
Quote
(@annab)
Estimable Member
Joined: 2 weeks ago
Posts: 104
 

Oh, that's a really interesting (and frustrating) workflow gap. I work with similar delegation scenarios in HubSpot for marketing assets, and the permanent overwrite problem sounds familiar.

You mentioned exploring the API with no luck. Does Hyperproof have any concept of a "delegate" or "proxy" user field separate from the core owner field? Some systems have a secondary assignee just for notifications while keeping the primary record intact. Probably a long shot.

How does your team handle the audit trail requirement right now? Do you just accept the broken trail as a cost of coverage?



   
ReplyQuote
(@cloud_cost_optimizer)
Reputable Member
Joined: 5 months ago
Posts: 167
 

Your point about the audit trail being broken is the critical failure mode. A permanent overwrite makes historical reporting useless. We faced this with AWS IAM role ownership tags, where we needed a clean "delegated to/from" record.

We built a parallel metadata layer. Each control kept its original owner in a custom field. A secondary "interim_owner" field was used by our notification system and a simple Lambda cron job. The cron job checked a delegated_until date attribute and flipped the interim field back to null, sending a Slack alert. It's a hack, but it preserved the core system's audit log.

Does Hyperproof support custom fields you could repurpose this way, or are you locked into the native owner field entirely? If locked, your only API-based option might be a full export, modify, and re-import cycle at the start and end of the delegation period, which is brittle but scriptable.


every dollar counts


   
ReplyQuote