Lesson 3.4: Security, access and compliance in a customer's environment
Working inside a customer's systems means working under their rules. Learn least access, secrets, masking, logging and compliance, and how to pass a review.
By the end of this lesson you will be able to explain how an engineer should behave inside a customer's systems: how to ask for the least access that will do, how to handle secrets and sensitive data, how to keep records of what you did and how to work with a security or compliance team so that approval comes sooner instead of later. You will learn a short list of security habits, a way to answer a security questionnaire honestly and a plain-language picture of the privacy law that now applies to most customer data in India. You will see three realistic situations handled and use a simulator to see how much risk careful scoping removes. This lesson closes Module 3. It follows the data audit of 3.1, the interfaces of 3.2 and the data quality work of 3.3, and it concerns the rules under which you do all of them. No security background is needed.
There is a mistaken idea that security is something other people do, a team that says no to engineers who want to get on with the work. In customer projects, the opposite is more accurate. You are a guest in the customer's systems, holding the keys to data that belongs to them and to their customers, and a mistake by you can harm real people and end the relationship. The customer's security team is not an obstacle. They are the people who protect the same things you are being trusted with, and the engineers who work well with them get approvals faster and are trusted with more.
Why customers are careful
A customer who lets an outside engineer into their systems is taking a risk, and they know it. Their data may include people's financial records, health details or identity documents. A leak can bring fines, loss of licences, legal claims and a damaged name. The people responsible for security have often seen incidents elsewhere, and their rules are shaped by them.
Three facts help you to see their side.
They answer for the outcome. If something goes wrong, the customer's security officer is the one explaining it to the board and the regulator, not you.
They cannot see your care. They know nothing about your habits. They judge you by your answers, your requests and your history, so a precise, modest request is your best introduction.
They have limited time. A team reviewing forty requests this week will approve the clear, narrow ones first.
If you take these seriously, many apparent conflicts disappear. The goal is to make it easy for them to say yes safely.
The habits that matter most
A small set of habits covers most of what a customer's security team will look for. Each is simple. The skill is in doing them every time.
1. Ask for the least access that will do
The principle of least privilege says a person or program should have only the access needed for the job, and only for as long as it is needed. It is the single most important habit.
In practice, before you ask for access, work out exactly what you need: which system, which tables or files, read or write, for how long. Then ask for that, not "admin access to the database". A request such as "read-only access to the repayment and account tables, for a service account, for ten weeks, with review at that point" is easy to approve. A request for everything is slow and may be refused. Narrow requests also protect you: if something goes wrong in a part of the system you could not touch, nobody will wonder whether you caused it.
2. Use your own named accounts
Never share a login, and never use someone else's. Ask for an account in your name, or a service account for the program, so that every action can be traced to the person or the program responsible. Shared accounts make it impossible to tell who did what, and customers' auditors dislike them intensely.
3. Keep secrets out of sight
Passwords, keys and tokens belong in protected storage, such as the customer's secret manager or protected settings, not in code files, messages, documents or screenshots. Lesson 3.2 made this point for integrations. Assume that anything you paste into a chat or an email is permanent and visible to others. Know how to rotate each secret, so that if one leaks you can replace it quickly.
4. Protect data in storage and in transit
Data should be encrypted when it is stored and when it moves between systems. Most modern systems do this by default, and your job is to not undo it: use secure connections, never copy sensitive data to unprotected places and check that backups and logs are covered too. If you are unsure whether a setting is secure, ask.
5. Collect and keep only what you need
The principle of data minimisation says to use the least data that will do the job. If your pilot needs fourteen fields, do not copy all hundred and twenty. If it needs a customer's pin code but not their name, do not bring the name. Data you do not hold cannot leak from your side, and the customer's security team will see the difference at once.
6. Mask and pseudonymise
Where you can, work with a version of the data in which personal details are hidden or replaced. Masking hides part of a value, as in a phone number showing only its last four digits. Pseudonymisation replaces an identifying value, such as a name, with a code, so that you can still follow one person's records without knowing who they are. Many tasks, such as testing a pipeline or checking quality, do not need real identities at all.
7. Keep production and test apart
Real customer data belongs in production. Development and testing should use fake or masked data. Mixing them is a classic source of leaks: a developer copies production data to a laptop to debug something quickly, and it stays there. If you need to reproduce a problem, ask for a small masked extract.
8. Leave a trail
Keep a record of what you accessed and what you changed, with dates. Most systems log access automatically, and you should add notes of your own: why you needed to look, what you did. When an auditor or a security officer asks months later, the answer should be a record, not a memory.
9. Follow the change process
Customers usually have rules for changes to their systems: a request, a review and an approval, sometimes a scheduled window. Even a small fix goes through it. Skipping the process to save a day is how outages and incidents happen, and it destroys trust.
10. Report problems at once
If you see something that looks wrong, such as data you were not meant to see, a key left in a file, or an action that did not go as planned, tell the customer's security contact immediately and plainly. A problem reported in an hour is an incident handled. The same problem found a month later is a breach of trust, whatever caused it.
Predict first: your pipeline is failing and you cannot find the cause. You think looking at a few real borrower records would explain it, but you only have access to a masked test copy. What should you do? Think of two things to avoid.
The right step is to ask the data owner or security contact for narrow, temporary access to the specific records you need, or to have a person with access check them for you, with a note of why. Two things to avoid are using someone else's login "just this once" and copying real records into your own tools to look at them. The first breaks the rule of named accounts and the second moves sensitive data to a place nobody has approved. A short request explaining the problem and the smallest access that would solve it is usually answered within a day, and it shows the security team the kind of engineer you are.
What you ask for, and what you need
A useful exercise is to compare what a pilot could ask for with what it needs. The difference is often large. A customer's loan table might have a hundred and twenty fields, from names and addresses to identity numbers. A reminder pilot needs about fourteen of them, of which a handful are personal. Everything beyond that is risk without benefit.
Writing this comparison down, field by field, is a strong first step in a security review. It shows that you thought about it, it makes the request specific and it lets the security team focus on the four sensitive fields, not the hundred and twenty.
Working with the security team
The customer's security and compliance people become much easier to work with if you treat the review as a conversation, not a hurdle. A few practices help.
Meet them early. In Lesson 2.2 you learned to find the gatekeepers in the first week. Security is the biggest one. Ask: "What will you need from us, and how long does it usually take?"
Bring a short document. A one-page summary of what you will do, what data you need and why, where it will run, who will have access and for how long. Reviewers value a clear, honest page far above a long, polished one.
Answer the questionnaire honestly. Many customers send a long list of security questions. Answer exactly: where you are not sure, say so, and where you do not do something, say so and explain what you do instead. A reviewer who finds an overstatement doubts the rest of your answers. A reviewer who sees plain, accurate answers trusts them.
Do not argue the rules. If a rule seems pointless, ask what risk it addresses. Often there is a good reason you did not know, and sometimes there is a different way to meet the same aim.
Offer designs that fit their rules. If the customer's rule is that data must not leave their cloud account, propose to run your software inside it. Designing to the rule gets approval much faster than asking for an exception.
Keep your promises. If you said access would end in ten weeks, make sure it does, and tell them when it has.
Worked example 1: the access request
A lender's collections pilot needs data from the loan system. The engineer's first instinct is to ask for "read access to the loan database". Before sending it, they write the narrower version.
They list the three tables the pilot needs, with the fourteen fields, and mark four as personal: the borrower's name, mobile number, language and due amount. They propose a read-only service account, restricted to those tables, with access for twelve weeks, after which it expires and is reviewed. They propose that mobile numbers be masked in anything the engineer looks at directly, since the message-sending component is the only part that needs the full number, and that component runs inside the customer's own cloud account.
The security officer approves in four days with one change: the service account must be reviewed at week six. A request that took a short document to prepare was approved quickly because every part of it was specific. The first draft, "read access to the database", would probably have gone back with questions and added at least a week.
The narrow request was approved quickly. The chart compares it with what the broad request would probably have cost.
Worked example 2: the debugging shortcut
In week five a pipeline fails for some accounts, and the engineer suspects the cause is in the real data. A colleague at the customer offers to share their own login so that the engineer can look directly at the production system. It is a friendly offer and would save half a day.
The engineer declines politely and explains: shared logins cannot be traced and would break the access rules the customer's own security team set. Instead, the engineer sends a short request to the data owner: "A pipeline failure affects about forty accounts. May a person with access check these ten account numbers for a blank in the language field and send me the result? No personal details are needed." The data owner does it within the hour, the cause is found and the fix takes ten minutes. The engineer notes the whole sequence in the project log.
The shortcut would have saved a few hours and risked a policy breach on the customer's side. The narrow request cost a few hours more and risked nothing. It also showed the colleague that the engineer could be trusted with larger things.
Worked example 3: the leaked key
A product engineer on the engineer's own team accidentally saves a test key for the customer's payment interface in a file that is committed to a shared code repository. The engineer notices it two days later while reviewing changes.
The response follows a clear order. First, tell the customer's security contact at once, before fixing anything: "A test key for your payment interface was stored in a code file on our side for two days. We have not seen any misuse. We are replacing it now." Second, rotate the key: ask the customer to issue a new one and revoke the old. Third, remove the file from the repository and check who could have seen it. Fourth, write down what happened, how it was found and what will change, such as a scanner that blocks commits containing keys.
The customer's reaction is calm, because the engineer reported quickly, did not hide anything and fixed the cause. A leaked key is an ordinary event in a software team. What turns it into a crisis is silence, and what turns it into evidence of good practice is a quick, honest response.
How much risk does careful scoping remove?
You can see the effect of least access and masking in numbers. If a pilot needs only a slice of the customer's records and works on masked data, the number of real, fully visible records on your side is far smaller than if you took everything.
The simulator below shows it. Set the total number of records in the customer's system, the share your pilot needs, the share of those you can mask, the number of people who will have access and the days they have it. It shows how many records are in scope, how many remain fully visible and the reduction compared with taking everything unmasked. It also gives the person-days of access, a rough measure of how many people hold access for how long.
The figures are illustrative, and the measures are simple counts, not a full risk model. Real risk also depends on how the data is protected, who the people are and what could be done with it. But the counts make the principle concrete: narrower scope and masking each multiply, and together they shrink the exposure to a small fraction.
Try three experiments. First, keep the defaults and see the reduction. Second, set the pilot's share to 100 and the masking to zero, which is "take everything, unmasked", and see what that looks like. Third, raise the number of people with access from three to twelve and see the person-days grow even when the records stay the same.
At the defaults, a pilot that needs 10 per cent of 500,000 records and works 70 per cent of those masked leaves 15,000 records visible with full details, 97 per cent less than taking all 500,000. Three people for sixty days is 180 person-days of access. Notice how each choice contributes: scope cuts 90 per cent, masking cuts a further 70 per cent of what remains, and a short, small access list keeps the exposure window narrow.
Compliance: the rules behind the rules
Beyond a customer's own policies there are laws. The details vary by country, sector and kind of data, and you are not expected to be a lawyer. You are expected to know that rules exist, to ask which apply and to follow what the customer's compliance team tells you.
In India, the Digital Personal Data Protection Act, 2023 sets duties for organisations that decide how personal data is used. Rules under the Act were notified in November 2025, and according to law-firm summaries most obligations on organisations take effect in stages, about eighteen months later, around May 2027. These duties are described as covering things such as taking reasonable security safeguards, using data only for the purpose it was collected for, keeping it only as long as needed, and handling a breach properly. I could not check the official text for this lesson, so treat the dates and the detail as a guide and ask the customer's compliance team what applies to them now.
Banks, lenders, insurers, hospitals and other regulated businesses may also be subject to rules from their own regulators about where data is stored, how outsourcing is managed and how incidents are reported. Ask the compliance officer early: "Which rules apply to this data, and what do they mean for how we work?" A short answer in week one can change the design.
A few ideas recur in almost every legal framework, and they match the habits above: use data only for a stated purpose, keep only what you need, protect it, keep it no longer than needed, let people see and correct their data and report serious incidents. If your practices follow the habits in this lesson, you will be most of the way to meeting these ideas without knowing the details of each law.
The timing of the Indian rules matters for a project that will run into 2027. The chart shows when parts of the rules take effect, as law-firm summaries describe them.
Handing back cleanly
When a project or a pilot ends, the security work is not finished. Before you leave:
End access. Confirm that your accounts and the service accounts have been disabled or handed over.
Rotate secrets. Replace any keys or passwords that you knew.
Remove copies. Delete any data you held outside the customer's systems, and confirm in writing.
Hand over the records. Give the customer the log of what was accessed and changed, and the documentation they need to run what you built.
Say what you kept. If your company keeps anything, such as anonymised statistics, say what and why, with the customer's agreement.
A clean handback is the last act of a trustworthy engineer, and it is what customers remember when they decide whether to work with your company again.
Common mistakes
Asking for broad access. Work out the specific tables, fields and time, and ask for exactly that.
Sharing or borrowing logins. Use named and service accounts so every action can be traced.
Secrets in code and chat. Use protected storage, and know how to rotate.
Copying production data to your laptop. Work on masked data in the customer's environment.
Skipping the change process. Follow it even for small fixes.
Overstating in a questionnaire. Answer accurately, and say what you do instead where you do not meet a requirement.
Arguing with the rules. Ask what risk they address, and design to fit them.
Hiding a mistake. Report quickly and plainly. Silence turns an incident into a breach of trust.
Forgetting the handback. End access, rotate secrets, remove copies and hand over the records.
Key takeaways
A customer's security team protects the same data you are trusted with. A narrow, specific request is the easiest to approve.
The core habits are least access, named accounts, secrets out of sight, encryption, minimal data, masking, separate test and production, a trail of what you did, the change process and quick reporting.
Compare what you could ask for with what the pilot needs, field by field. The gap is often large, and closing it removes most of the risk.
Meet security early, bring a one-page summary, answer questionnaires honestly and design to the customer's rules.
Laws such as India's Digital Personal Data Protection Act share common ideas: purpose, minimisation, protection, limited retention and reporting. Ask the customer's compliance team what applies now.
Report any mistake at once. Hand back cleanly: end access, rotate secrets, remove copies and hand over the records.
Check yourself
1. State the principle of least privilege in one sentence.
A person or program should have only the access needed for the job, and only for as long as it is needed.
2. A colleague at the customer offers you their login to look at production data. What should you do and why?
Decline and request narrow access, or ask someone with access to check specific records. Shared logins cannot be traced and break the customer's own rules.
3. What is the difference between masking and pseudonymisation?
Masking hides part of a value, such as showing only the last four digits of a number. Pseudonymisation replaces an identifying value with a code, so you can follow one person's records without knowing who they are.
4. With 400,000 records, a pilot needing 5 per cent and 80 per cent of those masked, how many records stay fully visible?
400,000 × 0.05 = 20,000 in scope. 20 per cent are unmasked, so 4,000 stay fully visible.
5. You find a test key saved in a code file on your side. What do you do first?
Tell the customer's security contact straight away, before fixing anything, and then rotate the key and remove the file.
Try this
This exercise takes about forty minutes and builds the access request for a pilot. Use the pilot you scoped in Lesson 2.3, or any project you know.
1. List every data source the project needs, with the system name.
2. For one source, list every field available, or estimate the count. Then list the fields the project needs. Mark any that are personal or sensitive.
3. Write the access request in one paragraph: which system, which tables or files, read or write, whose account, for how long and what happens when it ends.
4. Decide what you can mask or replace with a code, and what must be real. Write why.
5. Write three answers you would give on a security questionnaire, honestly, including one where you do not meet the usual expectation and what you would do instead.
6. Use the simulator to work out how many records would be fully visible, and compare with taking everything.
7. Write a short handback checklist: what you will end, rotate, remove and hand over.
A good result is a one-page access request with a field list, a masking plan, three honest questionnaire answers and a handback checklist. It is the security section of your one-page plan, and it is the document that gets a customer's approval sooner. It also completes Module 3: you can now find a customer's data, reach it, clean it and handle it safely. The next module turns to building in the field.
Sources
[India's Digital Personal Data Protection Act, 2023 brought into force](https://www.hoganlovells.com/en/publications/indias-digital-personal-data-protection-act-2023-brought-into-force-), Hogan Lovells, a law-firm summary. Used, with other summaries, for the point that the Rules were notified in November 2025 and that most obligations on organisations take effect in stages about eighteen months later. Sources differ on exact dates, and I did not check the official text, so confirm with the customer's compliance team.
The principle of least privilege, data minimisation, masking and the other habits are widely used security practices explained here in the author's own words. The examples, the loan-table figures and the simulator's defaults are the author's illustrations for teaching, not data from real companies, and this lesson is not legal advice.
Tags: Forward Deployed Engineer Security Compliance Data privacy Customer environments