The right access. The right data. Nothing unnecessary.
A salesperson should see the leads they own. A client should see their project. Neither should have access to system settings. We design that into the systems we build and connect, while the architecture is being drawn, not after the workflow already exists.
Access by design
Who should have access to what?
A login is an account. Access is a decision. A person's login should not expose every record in the system just because the record exists, so we scope what each identity can reach around dimensions like these:
- Role
- Responsibility
- Record ownership
- Organization
- Customer relationship
- Administrative authority
Access should follow the job being performed, not simply whether someone has an account.
| Resource | Sales | Operations | Admin | Customer |
|---|---|---|---|---|
| Leads & customers | Assigned records | No access | Broad | No access |
| Projects & jobs | Limited | Relevant jobs | Broad | Own project |
| Financial & admin | No access | If required | Relevant | No access |
| System settings | No access | No access | Authorized admins | No access |
Sales
- Leads & customers
- Assigned records
- Projects & jobs
- Limited
- Financial & admin
- No access
- System settings
- No access
Operations
- Leads & customers
- No access
- Projects & jobs
- Relevant jobs
- Financial & admin
- If required
- System settings
- No access
Admin
- Leads & customers
- Broad
- Projects & jobs
- Broad
- Financial & admin
- Relevant
- System settings
- Authorized admins
Customer
- Leads & customers
- No access
- Projects & jobs
- Own project
- Financial & admin
- No access
- System settings
- No access
An illustrative scope, not a template. The real matrix is designed around your operation.
Two different questions
How user and system permissions work
A system makes two separate decisions about every request. Authentication answers who is asking; a password, a session, a service proving its identity. Authorization answers what that identity may do, and that second decision is where most exposure actually lives.
01
Request arrives
A person or system asks for something
02
Identity verified
Authentication answers who is asking
03
Permissions evaluated
Authorization checks what that identity may do
04
Scoped access granted
The records and actions that fit the job, no more
Integration security
Every integration creates another trust boundary.
When two systems communicate, someone has to decide what crosses, in which direction, and on whose authority. We make those decisions explicitly, for our own connections and for third-party vendors alike: each side receives what its job requires, nothing more.
Your CRM
Or any system where your team works: it holds customers, jobs, and conversations.
Initiates requests
Trust boundary
proves its identity
reads: defined fields
writes: defined records
Passerelle integration layer
Credentials live here. Scope is enforced here. Activity is recorded here, so neither side needs blanket access to the other.
Trust boundary
scoped credentials
minimum required access
activity logged
Database / external service
Your source of truth, or a vendor tool with one defined job to do.
Answers within its scope
Decided at every boundary
- Which system can initiate requests
- How it proves its identity
- What data it can read
- What data it can write
- Which credentials it uses
- Where those credentials are stored
- What happens when credentials rotate
- Which actions are logged
- What happens when the integration fails
Where credentials tend to end up
- Shared documents
- Spreadsheets
- Front-end code
- Chat threads
- Shared notes
- Repositories where they do not belong
Where they belong
- Protected server-side configuration
- Scoped to one integration and one job
- Kept out of code that reaches the browser
- Rotation planned, not improvised
Data protection
Protecting stored and transmitted information
Connections use encrypted transport where supported and appropriate, so information is not readable as it crosses networks. Stored data gets protections matched to the database, the hosting, and the actual sensitivity of what is kept. And just as important: every portal, report, and integration receives the minimum information its job requires, because everything you send becomes something you have to protect wherever it lands.
The full internal record
- Contact details
- Service address
- Project history
- Estimates & pricing
- Internal notes
- Communication log
- Documents
- Source & attribution
- Account status
Everything the operation knows, in one place, behind the access rules above.
Customer portal
receives
- Project status
- Shared documents
- Appointments
Not internal notes, not pricing internals, not other customers
Reporting service
receives
- Aggregate totals
- Trends by source
Counts and totals, not full operational records
Third-party integration
receives
- The fields its job requires
Scoped to its function, nothing else crosses the boundary
What the browser never receives, the browser can never leak. And where payment processing is involved, we design around specialized payment providers, so raw card data stays with the systems certified to hold it rather than in yours.
When something goes wrong
Logging, recovery, and what happens when something fails
Where appropriate and in scope, sensitive actions are recorded so the team can answer “what changed, who did it, and when” instead of guessing. And a backup only matters if the system can actually be recovered from it: a copy nobody has ever restored is a hope, not a safety net.
Audit trail
actor · action · record · result
- m.alvarezrole.updated · operations team09:41 · applied
- s.okaforexport.customers · 214 records11:06 · recorded
- sync.crmproject.status · job 104211:52 · completed
Illustrative entries. Which actions are recorded, and with what detail, is agreed per system.
Recovery, decided per system rather than assumed
- 01What needs to be backed up
- 02How often copies are taken
- 03How long copies are retained
- 04Who can access them
- 05Where they are stored
- 06Whether restoration has actually been tested
- 07How the system would be recovered after a failure
How much data loss and downtime the business can tolerate is a business decision. It deserves to be made deliberately, not discovered during a failure.
An honest boundary
What Passerelle secures, and what requires a specialist
Our security work is architectural: the layers below, designed and tested as part of the systems we build and connect. Security is risk management, not a promise that nothing can happen.
One request, seven decisions
Public edge at the top, infrastructure underneath
- 01
Identity
Who is making the request?
Accounts and authentication for the people and systems that touch the operation.
- 02
Access
What are they allowed to see or change?
Roles and permissions scoped to responsibility, not to whoever has a login.
- 03
Application
Does the workflow enforce those rules consistently?
The same access rules on every screen, action, and API path, not just the obvious ones.
- 04
Connections
How do connected systems authenticate and exchange information?
Integrations with defined direction, scope, and credentials at every boundary.
- 05
Data
Where is information stored and who can reach it?
Deliberate structure, protected in transit and at rest as the architecture supports.
- 06
Infrastructure
How are environments, credentials, backups, and services configured?
Separated environments, protected configuration, and recovery that has a plan behind it.
- 07
Auditability
Can important actions and failures be investigated?
Agreed sensitive actions recorded with enough context to answer questions later.
No responsible team promises
- An unhackable system
- Zero vulnerabilities, forever
- No outages
- No human mistakes
- Third-party vendors that can never be compromised
What good engineering does
- Reduce unnecessary exposure
- Establish sensible boundaries
- Apply controls appropriate to the actual risk
- Design for recoverability
- Make important activity more observable
- Document the architecture and its assumptions
On compliance: frameworks like HIPAA, SOC 2, or PCI are commitments a business makes, not features a developer switches on. Where documented requirements are part of a project's scope, the architecture can be designed around them. That supports compliance work; it does not by itself make anyone compliant, and we do not claim certifications we do not hold.
Security is not a fifth product; it is a property of everything else we build, from custom systems to the data underneath them.
Process
Boundaries first, controls second, proof before handoff
Security work fails quietly too: a role that can see more than anyone intended, a credential that outlived the person who created it, a backup nobody ever restored. The process surfaces those on purpose instead of by accident.
- 01
Map the boundaries
Identify the users, systems, sensitive information, integrations, administrative access, and critical workflows involved.
- 02
Define access
Determine which identities and systems need access to which resources and actions, and just as importantly, which do not.
- 03
Design the controls
Establish the authentication, authorization, credential handling, data protections, logging, and recovery requirements appropriate to the architecture.
- 04
Build + configure
Implement the controls within Passerelle's scope and configure supported third-party systems appropriately.
- 05
Test the paths
Verify the important roles, permissions, integration behavior, denied paths, and recovery procedures included in the engagement.
Application and permission testing, not a formal penetration test. If your risk profile calls for one, the documented architecture gives a specialist something real to work against.
- 06
Document
Record the important access rules, dependencies, credential procedures, recovery information, and architectural decisions.
What you leave with
01A mapped access model
A clear picture of which users and systems should reach which resources.
02Defined roles and permissions
Access rules aligned with actual responsibilities, not with who happened to have an account first.
03Scoped system connections
Integrations designed so each connected system receives the access its function requires, without unnecessary privileges.
04Documented security decisions
The important architecture and access assumptions recorded, so they do not live only in a developer's memory.
05Recovery considerations
Backup and recovery behavior defined where those systems fall within the engagement.
06Tested application paths
Critical access and workflow behavior verified against the intended permission model.
Scope varies by engagement, and not every engagement includes every item.
Let's map who and what can reach your customer data.
We'll walk the users, systems, integrations, and access paths around your operation and identify where permissions or data exposure deserve a closer look.
Prefer email? Contact@passerelleint.com