Service5 of 6
Security and technical governance
We review a platform you inherited or are about to move to a new vendor. You get what we found, ranked by priority, and a plan to fix it.
- Category
- Security and technical governanceVerified
- Detailed capabilities
- Pending verification
- Engagement models
- Fixed-scope project
- Block of hours
- Handover record
- Repository · Documentation · Access · Infrastructure in your name
The surfaces of a system and who answers for them
Illustrative diagram. It does not represent any client’s architecture.
Every state
Public site
What anyone can open. The risk is in what runs in the browser and in what gets published by mistake.
- Trust zone
- Exposed to the internet
- Usual risks
- Scripts injected through content or dependencies
- Missing security headers
- Internal files published by mistake
- Who holds access
- Whoever publishes content, with their own account in the CMS. Nobody shares a login.
- Review
- Headers, content policy and what each deployment contains.
- Test
- Automated checks of headers and dependencies on every change.
- Record
- Publishing history with author and date.
API
The door to the data. Every request has to prove who it is and what it may do.
- Trust zone
- Exposed to the internet
- Usual risks
- Someone else’s record is read by changing an identifier
- Unvalidated input that reaches the database
- No limit on sign-in attempts
- Who holds access
- The applications, with their own credentials and narrow permissions. Keys do not live in the code.
- Review
- That every route authorizes per resource, not just per session.
- Test
- Tests that try to read and change another account’s data.
- Record
- A log of rejected requests and permission changes.
Administration
The most powerful panel. Few people, by name, and nothing shared.
- Trust zone
- Internal
- Usual risks
- Accounts of people who have left
- A shared administrator login
- Access without a second factor
- Who holds access
- A few named people, each with their role. Access is revoked the same day someone leaves.
- Review
- The list of accounts and roles, compared with the current team.
- Test
- Trying administration actions with a role that should not have them.
- Record
- Who signed in, when and what they changed.
Database
Where the valuable data lives. Nobody goes in directly except to operate, and it leaves a record.
- Trust zone
- Internal
- Usual risks
- Backups nobody has tried to restore
- Direct access by people for day-to-day tasks
- Personal data unencrypted at rest
- Who holds access
- The application, with a least-privilege user. People, only to operate and for a limited time.
- Review
- Database users, their permissions and where backups are kept.
- Test
- A backup restore from start to finish.
- Record
- Direct access and administrative queries are logged.
Integrations
Other people’s services that receive your data or act on your behalf.
- Trust zone
- Third parties
- Usual risks
- Keys with more permissions than needed
- Data sent that the service does not need
- Nobody knows who administers the provider account
- Who holds access
- One person responsible per provider. Accounts stay in your company’s name.
- Review
- An inventory of integrations: what data they receive and with what permissions.
- Test
- Rotating a key and checking that nothing breaks.
- Record
- Date added, last rotation and owner of each key.
Related scope: Vulnerability reviewArchitecture reviewAccess and permission hygiene
What it solves
Common situations, not client cases.
- P-01
You inherited a platform and don’t know what state it is in.
What changesA vulnerability and architecture review with prioritised findings.
- P-02
You are not sure who still has access to your systems.
What changesAn inventory of access and permissions, and how they are revoked.
- P-03
You are changing vendors and don’t want to lose control of the code or the accounts.
What changesAn orderly technical handover: repository, access and documentation in your name.
What’s included and what isn’t
Included
A search for known weaknesses in the code, the dependencies and the configuration.
How the parts of the system are arranged and what risks that arrangement introduces.
A review of the code, tests and conventions, with recommendations your team can apply.
Who has access to what, with which permissions, and how it is revoked when someone leaves.
An orderly transfer of code, access and documentation between teams or vendors.
Not included
Proposal pending approval- EX-01
Certifications or compliance audits
Not offered.
- EX-02
Penetration testing with a certification report
Boundary to be confirmed.
Boundaries proposed for review (A-07). They are not approved exclusions.
What you receive at the end
This is what you receive. Each row shows whether it passes to you, depends on the contract or is not transferred.
KorhyYour company
- Passes to you
- Per contract and model
- Not transferred
Final ownership is set by each project’s contract.
Base · in every service
- EN-01
Repository
The source code and its history, in a repository your company owns.
Passes to you
- EN-02
Documentation
How the system is built, why it was built that way and how to get it running.
Passes to you
- EN-03
Access
Admin credentials and permissions, handed to the people you name.
Passes to you
- EN-04
Infrastructure in your name
Cloud provider accounts in your company’s name. The exact arrangement is set by the contract.
Per contract and model
Specific to Security and technical governance
- EN-05
Prioritised findings report
What was found, where and with what priority, explained for those who decide and those who fix.
Passes to you
- EN-06
Remediation plan
What to fix first, who can do it and how to check it has been resolved.
Passes to you
What is not transferred
Proposal pending approval- NT-01
Our own tools from before the project
Internal accelerators we already had. You use them under a licence; they are not assigned.
Licensed for use per contract
- NT-02
Licensed third-party technology
Services and software from other vendors that the solution uses.
Subject to the vendor’s licence
Engagement models
We don’t publish prices: they depend on the scope. Response times, where they apply, are set in the contract.
A review has a start and an end: that is why it is contracted as a fixed-scope project or a block of hours, not as a retainer.
| Criterion | AFixed-scope projectEnquire with this model: Fixed-scope project | BBlock of hoursSelectedRemove: Block of hours |
|---|---|---|
| When it applies | When you need a full review of a platform, with a defined scope. | When you need a one-off review or help applying part of the remediation plan. |
| How it works | We agree which systems are reviewed, with which access, at which milestones and at what price. | Prepaid hours used task by task, with a log of what was done. |
| Deliverables | Prioritised findings report, remediation plan and a handover record. | Hours log and the documentation for each task. |
| Contract considerations | The price is set in the proposal. The access used is documented. | How long the hours stay valid, and on what terms, per the contract. |
- A
Fixed-scope project
- When it applies
- When you need a full review of a platform, with a defined scope.
- How it works
- We agree which systems are reviewed, with which access, at which milestones and at what price.
- Deliverables
- Prioritised findings report, remediation plan and a handover record.
- Contract considerations
- The price is set in the proposal. The access used is documented.
- B
Block of hours
- When it applies
- When you need a one-off review or help applying part of the remediation plan.
- How it works
- Prepaid hours used task by task, with a log of what was done.
- Deliverables
- Hours log and the documentation for each task.
- Contract considerations
- How long the hours stay valid, and on what terms, per the contract.
05Questions
Frequently asked questions
What people ask us most before starting.
It depends on the scope: which systems are reviewed, and how deeply. We set it in writing in the proposal before we start.
A prioritised findings report and a remediation plan, plus the access inventory and the documentation we reviewed.
Your team can do it with the remediation plan. We can also do it, through a block of hours or a separate project.
Yes. We can sign a confidentiality agreement and intellectual property agreements covering the deliverables.
Access passes to the people you name, and the inventory records who has access to what. The exact arrangement is set in the contract.
06Next step
Tell us which platform you need reviewed.
Online scheduling is not available yet.
Your enquiry
This comes with you to the contact form. The link only carries the service and the model.
- Service
- Security and technical governance
- Model
- Block of hoursRemove or change the model