FAQs

With encryption, permission-based access and a review before every release.

Only the people and systems that need it, with defined permissions.

Yes. We can review an existing app and tell you what to fix first.

Describe the information the app handles and who needs to use it. We discuss protection needs and access in the scope proposal.

Encryption is one part of the data protection approach described here. We define how it fits the project alongside access permissions in the proposal.

Describe what the app handles and the concern you want to review. We define the review scope and the changes to discuss before proceeding.

A role should have the access needed for its task. We discuss which information and actions each role requires before defining permissions.

List the tasks each type of user performs and what they need to view or change. We use that list to define permissions in the proposal.

Explain what the new role needs and what it no longer needs. We define the access changes to review in the scope proposal.

Browser code can be inspected by visitors. Private service keys should stay out of that code; we define the required connections and access in the proposal.

Private keys stay outside browser code. Required permissions are defined for each connection in the project scope.

Tell us which app and connections concern you without including secrets. We define what to review and any follow-up work in the scope proposal.

The review is part of the security approach described here. We define the changes, access and behavior to check for the project in the scope proposal.

Describe the screens, data connections and permissions affected by the work. That context helps define what needs to be reviewed.

We discuss the affected task and what needs attention before defining the next work. The scope proposal sets out the changes to address.