Skip to content

Requests & Changes#

Before demolishing a planet, Vogons put the plans on display in a cellar on Alpha Centauri, and because nobody objected, they considered the paperwork done. That's how bureaucracy earned its reputation: records are kept but nobody reads them, approval is requested but nobody can see it.

We do the opposite. When you ask for VPN access, request a firewall rule, or report a security incident, the request goes to the approver you nominated, it is never applied before approval, and every step — who asked, who approved, who carried it out, and when — lands in a tamper-evident audit trail. When your auditor knocks, you won't have to visit any cellars.

Who is this page for?

The request catalog is open to corporate customers under governance. If you have a compliance level such as PCI-DSS, the scope opens automatically. If you can see Compliance > Requests & Changes in the menu, you're in the right place.

Opening a Request#

The New Request button opens a catalog. Not a free-text box — a form that already knows which fields it needs:

Category Request type What it's for
Access VPN access request Granting one person access to systems over VPN
Change Firewall rule change Opening, modifying, or removing a network security rule
Incident Security incident report Reporting a security incident you have detected

The catalog is growing; new types appear in the same place as they ship.

The forms are smart#

Each type knows its own fields and doesn't ask for what it doesn't need. Tick Is this person external? on a VPN request and the form asks for the supplier company, their contact, and your internal sponsor — leave it unticked and those fields never appear.

The same logic governs validation: your form is never rejected because of a field you couldn't see. What's on screen is exactly what the server expects.

One VPN request, one person

If three people need access, open three requests. This is deliberate: a year from now, when someone asks "who was this access granted to", the answer has to be a single name. A bundled request can't tell you who still needs it when recertification comes around.

A justification is mandatory#

Every request carries a justification field and it cannot be left empty. "Because we need it" is not a justification — the sentence read out during an audit is the one you wrote.

Expiry dates#

Access requests ask for an end date. Access without an expiry is forgotten access — and forgotten access is access someone eventually finds.

The date you requested and the date we granted are kept apart: you may ask for a year, we may grant three months. The record honours what was granted.

Approval#

Your request goes to your own organization's approver. That is your decision, not VeriTeknik's — we are the party that carries the work out, not the party that authorizes it.

  1. The request opens with status Pending
  2. Team members with approval rights are notified
  3. Once approved, the VeriTeknik team picks it up
  4. When the work is done, the outcome is recorded and the request becomes Completed

We'll tell you if you have no approver

If nobody in your organization holds approval rights, you'll see a warning on the page. This matters: in an organization without an approver, every request falls to us — which is precisely the dependency this governance model exists to remove. An owner can fix it in one click.

Security incident reports don't wait for approval. Holding an incident in an approval queue does more damage than the incident itself — the report comes straight to us.

When we approve on your behalf#

If your approver can't be reached, the VeriTeknik team can approve on the customer's behalf. This path is deliberately kept open — a request shouldn't stall for days because your approver is on leave. But it is never silent: a justification is mandatory, you are notified, and the action appears in the audit record you export as a provider approval.

One-Time Secrets#

A request may end with us needing to send you a technical credential — a VPN password, a key, an initial passphrase.

We don't email those. An email is written once and then lives forever: your inbox, your backups, your search history. Instead, a box appears on the request detail:

  1. You press Reveal
  2. You're asked to confirm once (because there's no going back)
  3. The value appears on screen and you copy it
  4. The server-side copy is destroyed in the same moment

There is no second look. If you closed the tab by accident, ask for a new one — that's not an inconvenience, it's the design. We use the same approach for the initial password on your VPS servers.

Once shown, genuinely gone

The credential never enters a notification, an email, or a record row. It appears on that one screen, once. If you dismiss it unread, nobody — including us — can bring it back.

If a secret expires unread, the VeriTeknik team is alerted and a fresh one is issued to you.

Approved Documents#

If a document is attached to a request, the VeriTeknik team can mark it as an Approved Document. The badge shows who approved it, when, and the document's content digest.

The digest is the point: the approval doesn't say "a document was approved", it says "the document with this digest was approved". If the file changes afterwards, the badge turns into a warning. An approval stamp not bound to content is an unfalsifiable claim — and in an audit, an unfalsifiable claim is worth exactly as much as no claim at all.

Revoking an approval is a second event, not a deletion. The record must be able to say "this was once approved, and then revoked"; nothing in an audit trail is erased, only written over.

Topics Not in the Catalog#

The catalog doesn't cover everything, and it isn't trying to. If you need something outside these types, write in from Support — you'll find that link at the bottom of the catalog dialog too.

The reverse direction is open as well: when you open a support ticket on a topic the catalog does cover, you're pointed there. You shouldn't have to get lost between the two.

Your Compliance Level#

For organizations with a PCI-DSS level, the page shows two more things:

  • Responsibility Matrix (RACI) — for each of PCI-DSS 4.0's twelve requirements, which party is responsible, accountable, consulted, and informed. This is the table you show your auditor.
  • Support Tickets Awaiting Approval — the approval queue for change-type support tickets.

The matrix appears only for organizations that actually have a framework. A responsibility matrix that doesn't apply to you is something an auditor reads as a claim; we don't assign you obligations you don't carry.

The Audit Trail#

A request's entire lifecycle is written to a hash-chained audit ledger: submission, approval, rejection, assignment, completion, secret issuance, secret reveal, document approval.

Hash-chained means this: altering one record leaves every record after it inconsistent. Quietly correcting a single line isn't possible.

These records are yours

You can export your audit trail. You can also give your QSA auditor time-limited, read-only access — you shouldn't have to ask us to see your own record.

Questions? Open a support ticket — don't panic, we're right here.